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In thic TtciiA 

J List glance at an HP 48SX scientific expandable calculator running the 
^ EquationWfiter application and you realize immediately ttiat there's some- 
thing different about this calculator. The equation appears in the display 
almost as it would if you wrote it down on paper. The EquationWhter appli- 
cation is only one of this advanced handheld calculator's many new features, 
which also include enhanced graphics and plottmg, automatic units conver- 
sion, two-way communication with PCs and other HP48SXs, and two expan- 
' sion slots for additional memory or application software cards. You II find a 
I more complete list of features in the article on page 6. Also in that article, 
you can read about the internal software structures and mechanisms that support the feature set 
and the expansion cards. In the article on page 13, there's a discussion of how the HP 48SX 
manages multiple applications, followed by a description of some high-level built-in applications: 
MatrixWriter, EquationWhter, and the graphics and plotting system. The remarkable HP Solve 
Equation Library application card (page 22) gives you a library of 315 equations, the periodic 
table of the elements, a constants library, a multiple equation solver, a finance application, and 
engineering utilities — all on one card! The hardware design of the HP 48SX is described on page 
25. and the input/output system is described on page 35. Like some of its predecessors, this 
calculator has an infrared link to the HP 82240A/B printer, but unftke earlier designs, the HP 
48SX's infrared link is two-way, so that a patr of HP 48SXs can use it to exchange data and 
programs. There's also an optional RS-232 serial cable connection to personal computers. The 
HP 48SX is produced on the same production line and at the same time as earlier, simpler 
designs. The article on page 40 tells how. 

The traditional analog swept spectrum analyzer converts the input frequency range to an 
intermediate frequency by mixing the input signal with a swept-frequency local oscillator signal 
and filtering the result. The effect is the same as sweeping the filter over the input frequency 
range. By measuring and displaying the filter output, the analyzer shows how the input signal 
energy is distributed over the input frequency range. The bandwidth of the filter is called the 
resolution bandwidth of the analyzer and is usually selectable, but there's a trade-off. A narrow 
resolution bandwidth requires a slower sweep speed. All-digital analyzers, using digital filtering 
and the fast Fourier transform, offer both higher speed and extremely fine resolution, but only at 
relatively low input frequencies. The HP 3588A spectrum analyzer combines the traditional swept 
local oscillator (plus two fixed local oscillators) with digital resolution bandwidth filters and fast 
Fourier transform techniques. This allows it to make swept measurements four times faster and 
extremely fine-resolution narrowband zoom measurements hundreds of times faster than tradi- 
tional swept analyzers. Its upper frequency limit of 150 megahertz is much higher than all-digital 
analyzers with comparable speed and resolution in narrowband zoom measurements. In the 
article on page 44, the HP 3588A's designers discuss its principles of operation. Its design, and 
some of its features, such as self-calibration, hypertext help, and adaptive data acquisition. 
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Computer system diagnostic performance tools are used to diagnose abnormal situations such 
as poor terminal response time. They can reveal such thmgs as a process that is using an 
inordinate percentage of CPU time or a disk drive that is too heavily used. Typically, they Ve been 
applied fay technical experts and not much thought was given to making them easy to use. HP 
GlancePtus (see page 65) is a family of diagnostic performance tools designed to be easier for 
novice users to apply. There are three versions, one for each of the MPE V, MPE XL, and HP-UX 
operating systems. As much as possible, they all have the same look and feel, which is helpful 
in shops that have more than one kind of system, and they all use exception-based reportmg, 
which keeps uninterestfng data off the display so it can t confuse the user. 

Process improvement is a hot topic these days. Managers have learned that opportunities for 
quality and efficiency improvements are more easily identified by looking at a complete process 
rather than individual steps. At HP. product development is being analyzed as a single process 
that is jointly managed by marketing, manufactuhng. and R&D. As explained in the article on 
page 71, improvement efforts rely on the concepts of break-even time, postintroduction product 
reviews, in-process project retrospective reviews, and quality function deployment. 

Three papers in this issue are from the 1990 HP Software Engineering Productivity Conference. 
All deal with aspects of software development Two describe configuration management systems 
and the third tells how an HP division built a tightly integrated workstation network for the software 
development lab. The Domain Software Engineering Environment or DSEE (see page 77) is a 
configuration management system thaf s useful for managing software development projects from 
smallt simple ones to large, complex ones. It runs on the Apollo Domain operating system and 
is in use at over SOOO sites worldwide, inctudfng the HP Apollo Systems Division. HP's Imaging 
Systems Division took a custom approach to configuration management for the HP-UX operating 
system, basing their system on the HP-UX revision control utility RCS (see page 84). In planning 
their integrated project support network, HP's Roseville Networks Division had to consider finances, 
cooperative computing, network architectures, and system administration, including security in 
the traditionally open R&D environment. 

R.P. Dolan 
Editor 



Cover 

Two HP 48SX scientific expandable calculators can use their mfrared inpuVoutput link to ex- 
change data and programs. There's also a senal RS-232 cable link to a persona! computer. The 
cover photograph illustrates this dual capability (the 'infrared beam" is a lake, of course). 



What's Ahead 

THERE WILL BE NO AUGUST 1991 ISSUE! 

The next issue wiff be October 1991, Volumo 42, number 4. It will be produced on our new 
workstation-based pubfishing system and will have a new cover design and a different internal 
appearance. 

The October issue will present articles describing the design and manufacture of the HP 
Component Monitoring System, an advanced, highly modular patient monitoring system for the 
Intensive care unit and the operating room. Also featured will be the design of the memory 
controller, EISA connector, and BIOS of the HP Vectra 486 personal computer. Other papers will 
discuss software code inspections and estimating the cost of software defects. 
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The HP 48SX Scientific Expandable 
Calculator: Innovation and Evolution 

Many of the features of this advanced handheld calculator 
have evolved from its predecessors, the HP 41 C and fiP 
28S. Others, such as its unit management system, are new. 

by William C, Wickes and Charles M. Patton 



SINCE THE INTRODUCTION OF THE HP 65 in 1974, 
Hewlett-Packard has developed a succession of cus- 
tomizable scientific calculators of ever expanding 
capability. The HP 48SX scientific expandable calculator 
(Fig. 1) maintains this trend with an unprecedented com- 
bination of features and nexib))ity. Its oiajor features 
include: 

■ An RPN-slyle calculator inlerfaca with a dynamic stack 
of arbitrary depth for operations on eighteen types of 
mathematical or logical objects (plus twelve additional 
object types used by system programs]. 

■ Numerous arithmetic, transcendental, and statistical 
hmctions, applied uniform- 
ly wherever meaningful to 

complex as well as real 
numbers. 

■ Vector and matrix opera- 
tions on real and complex 
arrays of arbitrary size. A 
spreadsheet-! ike screen 
editor is provided for sim- 
plified entry and editing of 
arrays. 

■ Symbolic mathematics in- 
cluding evalualion, expan- 
sion, simplification, sum- 
mation, differentiation, and 
integration. The Equation- 
Writer application provides 
graphical, ''textbook" entry 
of expressions and equa- 
tions. 

■ String manipulations. 

■ Binary integer operations, 
with arithmetic, bit, and 
byte manipulations, and a 
vajiable word size. 

■ Numerical and symbolic 
equation solving. 

■ Eight types of automatic 
mathematical and statisti- 
cal plotting, including in- 
teractive root finding, cal- 
culus, labeling, and digitiz- 
ing. There are also interac- 
tive and progrannnatlc line 




Rg. 1 , HP 48SX saentiffc expandable calculator, showtng 
the EquationWrfter application. 



and arc drawing and creation of custom text and graphics 
displays. 

An integrated unit management system. Quantities that 
include physical units can be used in computations, 
solving, and plotting, while the calculator automatically 
performs unit conversions and dimension checking. 
Time management, including a clock/date display and 
appointment and program-execution alarms. 
Tw^o-W'ay communications via a wired serial port for con- 
nection to personal computers, printers, and other serial 
devices orvia infrared light for printing to the HP 82240A/B 
printer or for wireless transfers between two HP 48SXs. 

■ Customization with plug- 
in 32K-b>le or 128K-bytc 
RAM or ROM mem or}'' cards, 
w^bich may include com- 
mand libraries for extend- 
ing the built-in feature set. 
Libraries can also be im- 
ported into RAM using 
either I/O mechanism. 

■ A user-definable keyboard 
and custom menus. 

■ Programming in the RPL 
language, w^liich provides 
program-flow structures, 
recursion, global and local 
variables, passing proce- 
dures as arguments, input 
prompting and output hi- 
beling. user and system 
flags, logical tests and oper- 
ations, and user-defined 
functions. 
These features are supj- 

ported by a hardw^are st?t that 
includes a vertical-format 
package with 49 keys, a 131- 
by-B4-pixeI LCD display with 
support for fast scrolling of 
virtual displays that are larger 
than the physical screen, two 
plug-in slots for memon' cards » 
a four-wire serial communi- 
cations port, and an infrared 
transmitter aiid receiver (see 
articles, page 25 and 35). 
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Design Objectives 

The fundarnentaJ design objective for the HP 48SX was 
to create a product that comhines the software technology' 
of the HP 28S' uith the hardware flexibil% and customiza- 
bility of the HP 4lC.' Although in many respects the HP 
28S was itself a descendant of the HP 41 C. its advanced 
capabilities and limited hardware ha\e made its applica- 
tion and range of customers somewhat different from those 
of the HP 4lC For example, in the academic field, the HP 
41 C was very popular in college engineering departments, 
but it had little appeal to mathematics Lnstruclors. By con- 
trast, the HP 2SS has had a significant effect on mathematics 
instruction, with many colleges adopting it as a standard 
teaching tool. Engineering departments hav^e been much 
slower to adopt the HP 2SS, since it does not have the 
software exchange capabilities they are accustomed to with 
the HP 4lC Similarly, the HP 41C was verv^ popular with 
surveyors, but the liP 2SS is of limited use in this field 
because of its lack of 1/0 capability. 

The HP 48SX project started, therefore, with a review of 
the strengths of its two predecessors. The HP 41C's include 
plug- in memory ports. HP-IL I/O capability, a redefinable 
keyboard, and a vertical format convenient for hamiheld 
operation. The HP 28S's include extensive real and sym- 
bolic mathematical capabilities, RPL operating system and 
user language, a graphics display, and a menu key system. 

At the same time, we focused on common enhancement 
requests from HP 28S owners. These include a bigger dis- 
play, more graphics and plotting features, I/O capability, 
especially for importing or saving software, symbolic inte- 
gration, and more help from the calculator in using some 
of its more complicated features. 

All of these strengths and enhancements are incorporated 
in the HP 4aSX. In some cases, the implementation of one 
of these items evolved into a major feature that wasn't 
necessarily anticipated from the HP 2aS/HF 4lC combina- 
tion or a customer request. For example, the HP 2 BS's pow- 
erful numerical integrator was obscured by an arcane syn- 
tax for entering the integration arguments. Consideration 
of this problem in the HP 48SX investigation led to a review 
of the general problem of entering and recognizing mathe- 
matical expression.^, which ultimately led to the develop- 
ment of the Equation Writer application (see article, page 
13). This solves the integration problem— one enters an 
integral by "drawing" a textbook-It ke expression on the 
screen, including the integral sign, iipper and louver limits, 
and integrand, all appropriately positioned. However, the 
scope and utility of the Equation Writer far exceed what is 
needed for this particular use* 

The HP 4SSX also contains important features that derive 
more From "next bench'" research than horn BV 41C or the 
HP 28S strengths or from customer input. The prime exam- 
ple of these is the HP 48SX's unit management. ,Simple 
one-to-one physical unit conversions have been available 
on calculators for years. Several HP 4lC plug-in modules 
improved on this by providing a general-purpose conver- 
sion mechanism which could calculate any conversion fac- 
tor from input and output units specified as text strings. 
The HP41C Petruhum Fluids Pgc incorporates this mech- 
anism into its ca!c:ulation!? so that the user can InrJude 
units for the values entered for the programs, and ask for 



answ^ers in particular units. The HP 48SX taJces advantage 
of its multiple-object-type operating system and sxTnbolic 
manipulations to provide a new level of unit management, 
in which numerical quantities can have physical units 
attached to them and carried throughout arbitrary calcula- 
tions. The collection and cancellation of units and conver- 
sions between dimensionally consistent different units are 
handled automatically by the calculator. For example, a 
problem such as, "How fast is an object traveling after 
acceleratijtg at 1 m/s' for half a minute* if its initial speed 
was 20 mph?" reduces to 

(t_nri/s"2)v5_min-20_mph EVAL 

on the HP 48SX. which returns S71.1_mph. In HP 4aSX 
notation, the underscore _ acts as an object type identifier 
linking a floating-point number xvith a unit expression 
which can contain arbitrar^^ products, powers, and quo- 
tients of physical units. The HP 4aSX has 121 units built 
into ROM. from which the user can construct arbitrary 
compound units. Unit objects arc supported in numerical 
and symbolic calculations, plotting, equation solving, and 
integration. This HP 48SX capability removes a great deal 
of the drudgery from calculations involving physical units. 

In one aspect of the HP 4^SX design it was not possible 
to satisf>^ bulb HP 41C and HP 28S owners: programming 
language. To support its other design objectives, the HP 
48SX needed to use an RPL operating system and language 
similar to that used in the HP 28S. Unfortunately, this 
meant that the considerable body of programs written for 
the HP 41 C would not be executable directly on the HP 48SX. 
To solve this problem, the plug-in HP 8221 OA HP 4lC 
emulator card provides a keyboard emulation of the HP 
41 C and the ability' tn execute HP 4lC programs. The 
infrared port and the HP 82242A infrared printer module 
for the HP 41C can be used to transmit programs from the 
HP 4lC lo the HP 48SX for execution with the emulator 
card, 

HP 2HH users have a smaller problem in program conver- 
sion. The great majority of HP 28S commands can be exe- 
cuted without modification on the HP 48SX. Only a few 
commands are different, primarily those associated with 
display operations (and the integral command, as men- 
tioned previously], and the various system flags have 
changed. With optional software, the liP 28S can also use 
Its infrared printer output to "print" its programs to the 
HP 48SX, where they can be executed after minor or no 
modificcjtion. 

Internal Mechanisms 

The remainder of this article will discuss some of the 
mechanisms the HP 48SX uses to support its feature set. 
The memory maps shown in Figs. 2 through 7 illustrate 
the concepts discussed in this article. The implementations 
of many of the higher-level applications are discussed in 
the article on page 13. 

The fundamental basis of the HP 4BSX system is the RPL 
operating system, which occupies about 18K bytes of the 
system ROM. This system first appeared in the HP 13C 
Business ConsultEint calculator in 1986.' In brief, the system 
combines elements of Forth and Lisp, providing a multi- 



JUF^E 1991 H&WLETT-PACKARO JOURNAL 7 



)Copr. 1949-1998 Hewlett-Packard Co. 



Name Ffeld 



ROM PART ID 



Hash Taljlo Polntec 



Message Tabit Poiitmr 



Link Table Foint^f 



Conf toy ration Code Polntef 



Coltectiofi of Ob^s 



Rg. 2. Structure of a ROMPART, 

object RPN stack and direct and indirect threaded execu- 
tion, ivith both atomic and composite objects, temporary 
{lambda] variables, aiid the ability to pass unevalnated pro- 
cedures as arguments. The objects are similar to Forth 
words, containing the address of the executable code that 
defines the object and tlie data that makes up the body of 
the object. The object types provided in the initial versions 
of RPL were: 

■ Identifier class: identifiers (global names], temporary 
idenlifiers (local names), and ROM pointers [XLib 
names). These objects are used for storing and retrieving 
other objects. 

■ Procedure class: secondar>' (program) and code objects. 
These objects are executable. 

■ Data class: floating-point real and complex numbers, 
character and siring objects, hexadecimal strings (binary 
integers), real and complex arrays, linked arrays, 
extended precision real and complex numbers, lists, 
symbolic (algebraic), unsigned short integers, library, 
RAM/ROM pair (directory). Under normal execution, 
these objects merely return themselves, as passive data. 
However, symbolic objects and lists are composite 
objects, and can be evaluated like procedure class 
objects* 

The body of a composite object is a sequence of other 
objects terminated by an end marker that serves as a pro- 
gram return if the body is executed as a procedure. 

To support HP 48SX operations, several additional data- 
class objects were added to the above list: 
^^ Graphics object. These are LCD bit maps, used for storing 

and mEmipulating graphical images. 

■ Tagged object, A tagged object contains a text string plus 
another object. The lext is used to label the object. Oper- 
ations applied to the tagged object ignore the tag and 
apply themselves directly to the ''inner" object. Thus, a 
program might return the tagged object Speed:10_m/s, 
where Speed is the lag. Executing 10 • [times) then returns 
100_m/s. 

■ Unit object. This consists of a floating-point real number 
combined with an algebraic expression representing 
physical units. 

■ Backup object. This object is designed for the archival 
storage of a single object in an independently configured 
RAM port. The backup object contains a second object 
plus a name, a length field, and a checksum. The HP 
48 SX contains commands for storing and retrieving 
objects trom within backup objects when the latter are 
installed in RAM ports. 



■ Library data object. This object provides a memory buffer 
for use by plug-in applications that need to preserv^e data 
between executions. 

In addition to the new object types, three object types 
that were present in the HP 28S are given more visibility 
in the HP 48SX: 

■ In the HP 28S, a user can create a directory object stored 
in a variable, but has no access to the director\^ as an 
object. In the HP 48SX. a directory has the same status 
as other objects— it can be re c ailed to the stack, edited, 
copied, stored, and so on. 

■ Built-in commands in the HP 2BS and HP 48SX are 
organized in libraries, which are similar to compiled 
directories in which the linked list of named objects is 
compiled to a table- driven organization. Name resolu- 
tion of the objects within libraries is necessary during 
parsing, where text names are replaced by ROM pointers. 
The latter contain indexes into library object tables, 
wiiich in turn provide for fast location of an object's 
name and executable code. In the HP 48SX, libraries are 
available as ordinary objects* so that a user can move 
libraries in and out of the calculator via one of the I/O 
ports or on plug-in memory cards. When a library^ is 
installed in HP 4aSX memory, it extends the HP 4aSX's 
language by adding its own internal commands to ihe 
built-in set, 

■ ROM pointers are visible to the HP 48SX user as XLib 
name objects, the library analog of the global names that 
provide access to objects stored in global variables in 
RAM. Executing an XLib name executes the object within 
a library that is associated with the name. XLib names 



Jfiterrupi System 



RPL ICemeJ l%OMPAI^T 



mAM ROMPAHT 



Hidden ROm/ 
Code y 




Address ODDOO 



Links from the start 
Ot one ROMPART to 
the next. 



Built-in RAM 
(overfaps the 
hidden ROM) 
Address 80000 
Merged Plug-in 
RAM (see Fig. 4) 



Free Plug-iFi 
RAM (see Fig, 7) 



Address FFFFF 



Fig, 3, Overview of the address space layout of the HP 48SX 
calculator with one merged and one free (unmerged) RAM 
card. 
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can be compiJed as stand-alone RPN objects or included 

mthin ihe definitions of algebraic obfecis. As long as 

the relevant libran^ is present, an XLib name decompiles 

to the text name stored in the libran-. if the libran^ is 

removed, the XLib name is decompiled to show the 

librarv^ number and command number within the librani- , 

As part of the strategy lo maximize the use of ROM over 

RAM. the RPL system has included, from its inception, 

HOM-lIke slructujes that are analogs of the user's program 

and variable space (directories]. These are called ROM* 

P/VRTs, By attaching ROMP ARTs to subdirectories* the user 

can create a context-sensitive customization so that typing 

the same thing can have ver>^ different results depending 

on the context directory. ROMP ARTs were designed to 

provide context-sensitive customization, localizations of 

keywords and messages, system extensions, and run-time 

linking. 

In the process of developing a set of programs, the user 
first creates programs and utilities in a customizing direc- 
tory. When the programs are debugged and ready to keep, 
they can be transferred to a ROMPART and loaded into 
ROM. Attaching the ROKIPART to the same directory pro- 
vides the same functionality with less RAM use. 

RPL Plug-in Management 

While the overall scope and function of plug-in manage- 
ment did not change from the original RPL definition to 
its first released implementation in the HP 48SX, a number 
of design details did change in response to outside review^s 
of the system. Implementing these changes posed a number 
of design challenges. 

ROMPART Structure. A large portion of the RPL plug-in 
management design is based on the concept of a ROMPART. 
which is not a standard RPL object in the same sense as 
complex numbers, directories, programs, and so on, but is 
instead a set of data-structuro conventions. 

A ROMPART is a collection of RPL objects together with 
a field containing the name of the ROMPART. a ROMPART 
ID number which uniquely identifies the ROMPART. a 
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(see Fig. 5) 
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(see Fig, 6) 
~ End of Merged 
RAM 



Fig. 4. Overview of the tayout of HP 46SX main RAf\4 with 
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pointer to a hash table for use in identifying objects by 
name, a pointer £o a link table for use in identif\nng objects 
by theu- unique objecl numbers, a pointer to a message 
table containing messages specific to this ROMPART. and 
a pointer to configuration code which is executed whenever 
the ROMPART needs to be configured (see Fig. 2). 

The name 0eld can contain any characters and is used 
only as information for the user. The ROMPART ED number 
uniquely identifies the ROMPART to the system and Is in 
the range 000-7FE [hexadecimaj). ID numbers 000-OFF are 
reser\'ed for the RPL kernel and other built-in ROMP.\RTs. 
ID numbers 700-7FE are resen^ed for use by ROM PARTS 
providing application language extensions. 

The hash table provides a two-way correspondence be- 
tween names and objects in the ROlvIPART. It is used dur- 
ing the process of interpreting the characters typed in by 
the user to determine whether the characters name any 
object in the ROMPART, and then again to determine If an 
object should be displayed as a name rather than according 
to its internal structure. 

The link table provides a list (in object-number order) 
of all accessible objects within the ROMPART. 
Configuration. A ROMPART simply residing somewhere 
within the system does oot provide for any of the services 
described above. The RON/IP ART needs to be registered 
w^ith the system during the configuration process, which 
occurs in several stages. 

Whenever the machine is first turned on^ a routine check 
is made to see if any cards have been plugged in or removed 
from the system and adju^^tmenls are made lo compensate 
for the changes. Then a number of known areas are scanned 
for the presence of RO VIP ARTs and a list of currently extant 
ROMP ARTs and their locations is made and compared with 
the previous list. If no change is detected, the system con- 
tinues the normal process of turning on the display and 
resuming the state? it hiul when it was turned off. 

On the oLhar hand. iF a change is detected, the system 
performs its warm-start code. Among other things, the 
warm-start code resets any pointers that could be referenc- 
ing ROMPARTs that are no longer present. Thi.s includes 
the data and return stacks, updateahle system pointers, and 
the ROMPART pointers connected to the home directory. 
The system then rebuilds the table of ROMPARTs and their 
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and re;slarts KPL execution. 
HCHUPdll. One of Ihe first things done when RPL execution 
is restarted is to proceed through the current list of ROM- 
PARTs, executing each ROMPART's configuration code in 
turn. At this point, the KPL system is Ln a vslid. stable state 
and the full resources of the system are available for use 
by the conliguiation node. 

Although a ROMPART can tal^e over the system at this 
point (as is done, for example, by the HP 48SX demo ROM), 
typical tasks are much less ambitious. More typical exam- 
ples of tasks done at the ROM poll include: 
m Attaching a ROMPART to the home directory so thai the 

names of objects within the ROMPART are universally 

recognized. 

■ Replacing the hash and/or message tables of other ROM- 
PARTs with versions localized fora paj-ticukr language. 

■ Creating a LUistnm subdirectory structure for use with 
tliis ROMPART. 

ROM Poinlers. The RPL system/s ROM pointer (ROMPTR) 
objects provide a name and location independent metliod 
of spccitying an object within a ROMPART- The data in a 
ROMPTK gives both the ROM ID number nuique lo aROM- 
PAKP antl the particular olsject's object number. 

As long as a ROMPART has been registered as being 
present in the system ^ and independent of whether it is 
altached to any directory, ROMPTRs referring to a ROM- 
PART can be converted to the objecl or objects they specify. 
In this process, the cnrrcnt address of the ROM PART whose 
ROM in is specified in the ROMPTR is fonnd in Lhe ROM- 
PART table, and the ROMPART s link table is found, Tfie 
object number specified by the ROMPTR is used as an 
index into this table to find the actual current address of 
the specified object. 

ROMPTRs occupy a middle ground in terms of execution 
speed and flexibility between address pointers, which re- 
quire no resolution but must be updated whenever memory 
moves, and ordinary idenlifiers, whose value can change 
in thecourseof execuiionhutmust be resolved by searching 
through the current context. Every programmable fund ion 
and operation in the HP 48SX has an associated ROMPTR 
that specifies it. However, these are not normally used in 
programs since the address pointers will suifice. There is 
one case in which those ROMPTRs must be used, however. 
If the us6r stores a programmable function in a variable, 
what is stored is actually the corresponding ROMPTK, 
since storing an address pointer is contrary to the RPL 
conventions, and storing a copy of the object is clearly not 
what is desired. 

ROMPTRs are normally created in the process of convert- 
ing t3^ped-in lext to RPl objects [parsing). If the currently 
considered piece of text is not an object delimiter, number, 
or other tlxed-syntax item, it is considered to be a name 
whose meaning is determined by lhe current context. 
Names, ROMPTRs, and Localization. To determine the 
current interpretation of a name, the system first searches 
through all the variables in the current directory. If the 
name matches any one of these, the name is determined 
to be a variable name (ordinary identifier}. If not, the system 
searches through the hash tables of the ROMPARTs attached 
to the current directorv^ if ihere are any. If a match is made* 
the name is determined In be a ROM word name, and it is 



converted to the corresponding ROMPTR. If no match is 
made, the search is continued with the parent directory, 
and so on. If the home directory is searched without a 
match, the name is determined to be a formal variable (also 
an ordinary identifier). 

Every directory except the home directory can have at 
most one ROMPART attached to it. The hash table used 
in searching such a ROMPART is the one supplied with 
the ROMPART. The home directory, on the other hand, 
can have multiple ROMPARTs attached to it. Recorded 
with any ROMPART attached to the home directory is a 
pointer to its hash table. This allows the hash table pro- 
vided by a ROMPART to be superseded by another hash 
table cither in RAM or in another ROM (locaUzation). Only 
ROMPARTs attached to the home directory can be so 
localized, 

Structure ol Plug-in Modules. The original RPL design pro- 
vided for two kinds of plug- in modules: one associated 
with read-only devices (ROM) and one associated with 
read/ write devices (RAM). Whenever a ROM device was 
detected, it was assumed that Its data consisled of a linked 
list of ROMPARTs. The devices would be configured ai 
some convenient but otherwise arbitrary address and the 
individual ROMPARTs would be registered as described 
previously. Whenever a new RAM device was detected, it 
was assuiued that the device contained no viable data and 
the device would be configured to be a contiguous segment 
of the system's overall RAM, with current RAM contents 
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Fig. 6, Layout of the USE ROB area and port A itbrary or 
ROMPART attached to the home directory ROMPART attach- 
merit table, either by the attach command or during lhe 
ROM poll, will have fts keywords recognized by the system 
and can have both its f^eywords and its messages (ocaHzed 
(for example, translated into other fanguages). 
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shifted to new positions as necessary. This process is 
knowe as merging KAM. After RAM has been merged, it is 
not possible to unplug the module without endangering 
the system int^rity. When a merged RAM Ls pulled, a large 
area of the system and user variables could go with it. 

To make it possible to have ROMP.'\RTs vvithoot read- 
only devices, an area within system RAM is set aside and 
given the same structure as a plug-io ROM, that is. a 
sequence of ROMP.^Ts, This R.\M*based ROMP ART area 
is also searched during the conBguration of ROMPARTs. 
This model for plug-in structure provides almost all avail- 
able services automatically and requires only five user- 
level commands: to prepare the system for removal of a 
RA^I module (FREE) by reversing the procedure used to 
merge the RAM module, to attach and detach a given librar\^ 
from a given directory, to include a ROMP .ART (given in 
some object-coded form) in tlie R.'lM-based ROMP ART 
area, and to remove such a ROMP ART. 

Design Changes and Challenges 

In the evolution of the HP 4BSX design, it became appar- 
ent that RAM modules needed to he used as mass-storage 
devices as well as system RAM. By analogy to tlexible disks, 
one would expect that such a mass-storage RAM module 
could he removed without first informing the system. These 
two tenets had significant impact on the HP 48SX plug-in 
management design. Other factors that affected the design 
were that the RAM modules have a switch that allows them 
to act as ROM, that there is no effective way to determine 
the size of a ROM module, and that th*T systf^m cRnnnt 
reliably detect the removal of a plug- in as it is happening. 
Backup Objects and Libraries. To use a RAM card as mass 
storage, we need to be able to store name/object pairs in 
the RAM card much as they are stored in variables in the 
main HAM. In addition, we need to be ahle (o verify that 
the data on the card has not been corrupted in some way. 
This verification stage must be fast because it musl happen 
at configuration time, that is, between the time the machine 
is turned on and the time the machine is available for use. 
Since no stand-alone object consisting of a rtanie/ohject 
pair existed in the original RPL system, a new object type, 
the baclcup object, was invented for the purpose. A hackup 
object, in addition to its prologue and leagih. con si sis of 
a name, an object, and a checksum, 

Sint:e ROMPARTs can coexist with backup objects In a 
plug-in, they are also encapsulated with a prologue and a 
t:hecksum to become library objects. 

The organization of the data in a ROM plug-in is largely 
dictated by the fact that the system can only determine the 
beginning of a ROM and not ihe end. This means that any 
data structure within the ROM must start at the beginning 
address and extend from there. The original RPL configura- 
tion assumed just such a structure, so that converting the 
configuration from a linked sequence of ROMPARTs to a 
sequence of backup and library objects was relatively 
straightforward. The system determines the end of the 
sequence when it finds either an end-ol'Sequeju:e mark, 
an object that is not a backup or library object, or an invalid 
checksum. In either of the la.5t two cases, the user is warned 
of Invalid Card Data, but no further remedial action is taken . 

Sinco RAM plug-in cards can be t:onvertt>d to the equiva- 



lent of ROM cards by simply changing a switch setting on 
the card, we decided that the structure of an un merged 
plug-in RAM card should be the same as a ROM card, that 
is. a sequence of library and backup objects with the 
sequence starting at the lowest address of the card. 
Ports* The RPL directorv" structure Is one of the most tightly 
Integrated aspects of the system. Having been conceived 
of as semipermanent storage which could dominate the 
use of free memor>' in a memory-limited system, it is 
implemented as a self-contained unit containing no point- 
ers that need to be changed as other parts of memory' 
change. In addition, it is relegated to the high -ad dress end 
of free memDr}^ 

This highly integrated structure with no provision for 
referring outside itself precludes the inclusion of unmerged 
RAM cards as virtual subdirectories of the home directory. 
We decided to extend the mass storage analogy further and 
have separate data storage space locations analogous to 
flExible disk drives. Instead of drives A. B, and C* we have 
ports 1> 2. and 0. Ports 1 and 2 refer to the data contained 
in cards plugged into the corresponding^ plug-in slots. Port 
refers to an area in built-in RAM that acts like a permanently 
plugged -in card (see Fig. 6), Unlike personal computer mass 
storage, however, the current drive is never any of these. 
The port specification must be included in the information 
giv^en to any operation invnh'ing the ports. 

The normal STO, RCL, and PURGE commands, which nor- 
mally store< recall, and delete variables in main memory, 
are extended to allow^ transfer of information to and from 
the ports. Tagging a name argument with :0:. :1:. or :2: indi- 
cates to these commands that a port operation is desired. 
For example, if ABC is the name of an object in port 0. then 
:0:ABC RCL will return the object to the stack. 

Since the only kinds of objects allowed in a plug-in data 
area are hackup and Hhrary objects, any other kind of ohject 
is first encapsulated as a backup object. Similarly, RCL of 
one of the bj^ckup objects will pry the object out of the 
capsule. 

Directory Management Extensions. The fact that the cur- 
rent drive is always none of the ports has several conse* 




y»tr Vmriables 



Llbrafy or Bacliiip Object 



tlbtaiy or Backyp Object 




Fr&e Plug-in RAM 
) or 

Plug^in ROM 



Ej>d-c)f'5»quer»c« Mark 



'4SSBSBSSBSSSSi 




Address FFFFF 

Fig* 7. Layout of an unmerged (free) piug-in RAM CBrd within 
the HP 48SX address space. An unmerged ptug-fn card /s 
mtherport J or port 2 and has the same structure as port Q. 



JUNE 19S1 HEWLETT-PACKARD JOURNAL 11 



)Copr. 1949-1998 Hewlett-Packard Co. 



qtiences. First, simply transferring a working set oT related 
programs from a directory to a port will not result in a 
working set of programs in the port. This is because of the 
port -specific reference tor names. If the program calls a 
subprogram by including its name, say SubProgI EVAL. then 
only the directory is searched when the name is to be 
evaluated. On the other hand, if the subprogram is called 
by including a port-specific reference, say :0;SubProg1 EVAL, 
then only the specified port is searched. To compensate 
for this, we have included a "wild card'' port specifier, :&:. 
The sequence :&:SubProg1 EVAL will search for the subpro- 
gram in all ports and then in the current directory before 
giving up. This calling sequence allows programs to be 
executed from directories or ports interchangeably, 

A second consequence of there being no current drive 
is the lack of access to objects contained in directories 
stored in a port. Normally, the method of accessing an 
object in a directory is first to change context to the direc- 
tory and then to use RCL or some other command. Since 
it is not possible to change context to a directory stored in 
a port, this method ts not available without first copying 
tlie directory back to main RAM. This is solved by using 
a list as a complete path specifier for recalling a variable. 
For example^ if A is a directory^ object stored in port and 
it contains a variable B, then :0:{ A B ] RCL will recall the 
contents of B to the stack. Similarly, it is possible to recall 
from any location without changing the context directory 
by using a list to specify the path completely. 
Archive and Restnrp. With a method of mass storage avail- 
able, it is natural lo provide a means to archive the curren! 
contents of the calculator and later to restore this informa- 
tion. The operation ARCHIVE produces a copy of the entire 
home directory encapsulated as a backup object. It delivers 
this copy either to a specified porl or to another mad line. 

Restoring from a backup copy of the home directory using 
the RESTORE operation reverses the archive process. 
Because of the potentially greater need for human interven- 
tion, RESTORE will not automatically restore from another 
machine. Instead. RESTORE will use a backup [or any other] 
copy of the home directory no matter how it was obtained. 
RAM Recovery. With the large amounts of data that can 
be present in the machine, it is clear that additional data 
safeguards are necessary. One such safeguard is provided 
by the Recover RAM? operation. 

Whenever it is found that the structural integrity of RAM 
has been violated, the user is given the opportunity to 
either start with a clean slate or attempt to salvage some 
data. If the user chooses to salvage data, the machine first 
searches through RAM. locating library or backup objects 
whose checksums are valid. It collects all of these into a 
new port 0. 

It then searches for a directory object having the specific 
features of the home directory. If one is founds the RAM 
recovery operation verifies its structural integrity, and the 
operation is complete. To check the directory's structural 
integrity^ the fi.'\M recover}- operation checks the structural 
integrity of each object within the directory [including 
recursively checking subdirectories) and removes any that 
are corrupt. If no home directory is found, the RAM recov- 
ery operation begins searching for ordinar\^ directory 
objects. When it finds a directory it checks the structural 



integrity of each object within the directory (including 
recurs iveiy chec:king subdirectories) and removes any that 
are corrupt. 7 he resulting corrected directories are named 
D.O, D.I, and so on. and are gathered togelher to form a new 
home directory, completing the recovery process. 
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HP 48SX Interfaces and Applications 

The HP 48SX scientific expandable calculator provides 
support for multiple applications, both built-in and externally 
developed, with customized user interfaces. The Equation- 
Writer and interactive plotting are two of the built-in 
applications. 

by Ted W. Beers, Diana K, Byrne, Gabe L. Eisenstein, Robert W. Jones, 
and Patrick J, Megowan 



LIKE ITS PREDECESSOR THE HP 2 8S. the HP 48SX 
scientific expandable calculator is an RPN calcuiator 
designed as an electrortic scratchpad for mathemat- 
ical calculations. However, the simple user interface used 
in the HP 28S would have become overloaded if translated 
directly to the more capable HP 48SX. Consequently, the 
HP48SX contains direct support for developing specialized 
user Interfaces that can replace or extend the basic cal- 
culator interface. The support is used in the built-in appli- 
cations such as the Equation Writer and interactive plotting, 
and is available for ordinary user programming and for 
externally developed applications. In this article, we \\\\\ 
review the support mechanisms and give several illustra- 
tions of their use. 

Managing Multiple Applications 

Early in the developmiMit of the HP 48SX, it became 
apparent that without a common approach to application 
interface implementation, the calculator would not present 
a consistent methodology to the user. For example, when 
an application ends* it is important that the menu displayed 
before the application was started be rostoredn If one appli- 
cation restored the previous menu while another always 
disp laved the MATH mf?nu. user confusion would result. 

Although a consistent approach to application interface 
design is important* so is the freedom of the designer to 
incorporate unique features that justify the need for a spe- 
cial Interface. One of the challenges in developing the 
application interface engine for the HP 48SX was balancing 
consistency of operation with flexible design components. 
For the basic, stack ^orientedn RPN operation of the 
HP 48SX. and for stack-oriented applications such as statis- 
tics, the user interface is handled by the built-in RPL outer 
loop. All other applications use an RPL tool called the 
parameterized outer loop, which is designed to customize 
a user interface. 

The designer of an application can be expected to know- 
how its interface should operate^ but not necessarily to 
know or fully understand how^ the application should han- 
dle the application from which it was started or how^ to 
respond consistently to fatal error conditions and other 
unexpected events. The parameterized outer loop relieves 
the designer of these burdens while providing a common* 
robust method for haodling application startup, applica- 
tion shutdown, and asynchronous event handling. The 
parameterized outer loop accomplishes this by handling 



the foUoW'ing major aspects of calculator operatiom 

■ Saving the previous application's user interface 

■ Updating the application's display between key presses 

■ Waiting for and dispatching key presses, alarm inter- 
rupts, and unhandled errors 

■ Exiting the display and key handling loop 

■ Restoring the previous application's user interface. 
Except for saving and restoring the previous application's 

user interface* the application-specific components of each 
step are specified by the application when it starts the 
parameterized outer loop. 

Before the user can interact with an application such as 
I he Equation Catalog, the application must set its user inter- 
face. The user interface is what makes the interaction with 
the application unique. For example, in the Equation Cat- 
alog, the familiar stack display is replaced by a list of equa- 
tions, and the T and A keys no longer move the character 
cursor but instead move a list pointer around the equation 
list. An application sets these and other aspects of its inter- 
face when started by passing a set of user interface param- 
eters to the parameterized outer loop. These parameters 
define how the application manages the HP 48SX display 
and keyboard and how the application interacts wiLh thn 
rest of the calculator environment. 

Parameterized Outer Loop Operation 

The operation nf the para met eri/ed outer loop can he 
summarized as follows; 

Save the system or current appi teat ion's user interface 
ff en^or m 

{ Set the new appfi cat ion's user interface 
While exit condition object evafuates to FALSE 
i Evaluate display object 
If error in 

Read and evaluate a key 
Then 

Evaluate error handier object 
} 
I 
Then 

Restore the saved user interface and error 
Restore the saved user interface 

The application specifies the unique operation compo- 
nents, such as the exit condition objettt and the display 
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object, when it starts the parameterized outer loop. This is 
how the application Eiuu^tomizes the interface. The 
parameterized outer loop is responsible for the key-display 
loop, alarm interrupts, and low-level error handling. 
Display Handling, There is no default display in the 
parameterized outer loop. The application is responsible 
for setting up the initial display and for updating it. The 
application display object is the method by which ttie 
application manages the HP 48SX display. This ribject. 
which is usually an executable program, can take advantage 
of the two main methods of displaying information that 
the HP 48SX sijpf>oris: passive display update and active 
display update. 

Passive Display Update. Passive display update involves 
using the display object to update any area of the display 
that needs to he changed after a key is handled. In this 
display handling model, each key is responsible for implic- 
itly passing information to the display object regarding 
what areas of ihe display it hasn't changed. The display 
object then updates all other display areas. 

Sixice the main outer loop itself uses this display update 
scheme, applications that use many standard keys, such 
as MatrixWriter. take advantage of the display update in- 
formation passed by the standard keys to simplif\^ their 
own display and key handling logic. 

A m;tjor benefit of passive display update rests on the 
fact that the application programmer can make no display- 
related assertions at all in key handling, and still the display 
handling will work properly, albeit more slowly than nec- 
essary. As the application devt^lops, the programmer can 
add assertions to those keys that do not affect certain dis- 
play areast thus saving time during display update. If the 
programmer misses a few combinations of key-display 
interaction, the application stills operates properly. 
Active Display Update. The second method supported by 
the parameterized outer loop for handling display update 
is the more conventional active display update- In this 
model, each key that affects the display updates the display 
itself. With active display handling, the application display 
objecl can be reduced to a simple NOP [no operation). The 
major drawbacks of active display update are that all aspects 
of display handling must be considered by every key defini- 
tion, and the implicit display update information required 
by other calculator resources must be determined whenever 
these resources are used by the application. 

For consistency and robuslnessT most HP 48 SX applica- 
tions manage the display in the same manner as the main 
outer loop, namely with passive display update. 
Hard Key Assignments. Any of the HP 48SX keys, in any 
of their six planes (unshifted, left-shifted, right-shifted, 
alpha-unshifted, alphad eft-shifted* and alpha-right-shifted) 
can be assigned for the duration of a parameterized outer 
loop application. The key object parameter specifies the 
keys to assign and Iheir new assignments. In addition, there 
are two flag parameters that control how keys not assigned 
by the application are handled. If a key is not assigned by an 
application, and the alfow default keys flag is TRUE, then stan- 
dard or default key processing occurs, according to the do 
standard keys flag. 

For example, if user keys mode is on and the key has a 
user key assignment, then the user key is processed if do 



standard keys is FALSE, or the standard key is processed if 
do standard keys is TRUE. If allow default tteys is FALSE, then all 
nonapplication keys beep and do nothing else. 
Menu Key Assigiunents, An application can ,'>pecify any 
initial menu key assignments, in any of three planes (un- 
shifted, left-shifted p and right-shifted), to be initialized 
when the parameterized outer loop is started. An outer 
loop parameter specifies the definition object for the appli- 
cation's menu, and may indicate thai the current menu is 
to be left intact. When the outer loop is exited, the previous 
menu is restored automatically. 

Since hard key assignments have priority over menu key 
assignments, it is possible to define more exotic behavior 
for the menu keys. To date, no parameterized outer loop 
application does so, however, since the menu key handling 
is very flcx1bh:i and customizable itself. 
Preventing Suspended f^^nviranments. Many applicatiotis 
need to allow arbitrary cornmands and user objects to be 
evaluated, but may not want the current environment to 
be suspended by the HALT and PROMPT commands. A pa- 
rameterized outer loop flag specifies whether any comniand 
that would suspend the environment instead generates a 
HALT Not Allowed error. Since both HALT and PROMPT actual- 
ly restart the main outer loop, which leaves the application 
suspended indefinitely without protection for its global 
resources, all current applications disallow suspension. 
Nesting Applications, One of the powerful features of the 
HP 48SX is its ability to stm:k or nest muftiple applicalion 
user interfaces, effectively allowing an application to run 
wilbin another application. For example, while working 
vvitlrin Ma I rix Writer, one can press | STK to start the interac- 
tive stack application to copy a value from the stack into 
MatrixWriter. Conversely^ within the interactive stack, one 
can select a matrix and press VIEW to start MatrixWriter. 
In both cases, when the set:ond application is finished, the 
first resumes where it left off. The parameterized outer 
loop makes sure all the details are sorted out. 

Application Examples 

The interactive stack is an HP 48SX application with 
which one can browse through the HP 48SX data stack and 
perform a set of stack-related operations based on the 
selected stack levels. Since the interactive stack is designed 
for stack operations only (including some object editing 
operations), it maintains strict control over the keyboard 
and display. This is accomplished with its key handling 
and menu objects. Unlike most applications, the interactive 
stack presents a different menu depending on how it is 
started. When an edit line doe.s not exist, a full menu of 
operations is displayed. When an edit bne does exist, the 
interactive stack displays a more restrictive menu, reflect- 
ing the fewer operations available. To implement this differ- 
encet the interactive stack passes one of two menu objects 
to the parameterized outer loop as its menu specification, 

MatiixWriter is an HP 48SX application tliat simplifies 
the entry of matrix objects* Like the interactive stack, Matrix- 
Writer controls certain keys that are redefined for its envi- 
ronment, such as A. Unlike the interactive stack, however. 
MatrixWriter allows ail undefined keys to operate normal- 
ly, since many standard key definitions, such as +■ are 
useful in MatrixWriter. 
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Both the interactive stack and MatrixWriter use the pas- 

sive display update method for managing their output. In 
the case of MatrixWriter. this is especially useful and 
importajnt, since the standard edit line interface is used 
extensively withiti the MatrixWriter anvironment. 

Custom fzatlon by the User 

Tiie standard keyboard and display uf the HP 48SX are 
designed for general use, offering direct access to numerical 
computation and indirect access to olher features. For users 
who want direct access to features of their own choosing (or 
creation] * the HP 48SX has a number of tools for customiz- 
ing the user interface. The user can redefine keys* define 
a custom menu, customize how key definitions are exe- 
cuted, and maintain, a variety of customized environments. 

In the HP 28S, key definitions are objects of a special 
form. For easier customization, we changed the HP 48SX 
so that any object can be a key definition. For example^ 
the user can assign the string 5 and the function + to keys, 
and those keys will act the same as the normal 5 and + keys. 

For each key. the user can assign an object in one of six 
key planes: keys can be unshifted, lefl-shifted. or right- 
shifted with alpha on or off. If key assignments are viewed 
as yet another shift, this makes 12 key planes in alL The 
user can enable or disable the current assignments by press- 
ing ♦lUSR, or by setting or clearing a flag. The assignments 
can he recalled as a list of alternating key codes and objects » 
and such a list can be used to make assignments. 

Another way to define keys is the ciistom menu. After 
storing a list of objects in a variable named CST. the user 
can press CST to put the first six objects in the menu* NXT 
to put the next six objects in the menu, and so on. This 
method doesn't involve the key assignments described 
above; rather* it uses the standard key definitions that make 
the menu system work. 

The objects in the custom menu are given the same 
shifted interj^retations as in buih-in menus. For example, 
a name is executed, stored into, or recalled, depending on 
whether the key is uoshlfted. left-shifted, or right-shifted, 
just as in the VAfl menu. Units are muUi plied, converted, 
or divided, just as in the units menu. Alternatively, the 
user can spt^cify separate objects for tbe menu label and 
for unshifted, left-shifted, and right-shifted actions. 

The most radical customization is called vectored EI^TER, 
When the user pre.sses a key in normal operation, the cor- 
responding object is either written to the command line or 
executed. In the latter case, the text already in the command 
line must be parsed and executed first, and then the key- 
definition object is executed. The user can custom i:se two 
steps in this process by storing programs in variables 
aENTER and p ENTER. 

The program in otENTER takes over parse-and-execute 
responsibilities. Such a program might either (1] print the 
command-line text and then execute OBJ->, which parses 
and executes as usual, (2) modify the text and then execute 
OBJ^, or (3) parse the text itself. 

After the key-definition object is executed, its tt^xt form 
is given to pENTER as an argument. Such a program miglit 
print the text mid the contents of the stack, drop the text 
and modify the results on tbe stack, or display status infor- 
mation or otherwise prepare for the next input from the 



user, 

\'ectored EfsTTER is enabled by setting hoth its own flag and 
the flag for user key assignments. The latter condition 
allows the user to disable vectored ENTER from the keyboard. 
This safety feature is important, since faulty customization 
routines can totally disrupt calculator operation. 

Finally, the user can main lain a variety of interfaces cus- 
tomized for different purposes. Since the custom menu 
and vectored EISTTER are defined by variables, switching 
directories can cause the interface to change accordingly. 
On the other hand, key assignments are independent of 
the director}'. By assigning directory-switching programs 
to keys, the user can readily sv%itch from one interface to 
another. 

Ttie EquationWriter 

The primar}' design objective of the EquationWriter was 
to overcome several factors limiting the ease of use of exist- 
ing calculators. The EqualionVVrilsr is the first application 
to emerge from advances In display technology, both hard- 
ware and software, compared with the HP 2BS. The general 
result of these advances can be seen in the inclusion of the 
graphic object data t^pe and the virtual screen of the HP 48SX. 

The basic idea of the EquationWriter is lo show mathe- 
matical expressions as they appear in textbooks nr as nor- 
mally written by hand— for example: 

■ N u mera t o rs ab o ve deno minat ors > sep arated by a horizon- 
tal Una 

■ Exponents vvritlen as superscripts, in a smaller font 

■ Parentheses of adjustable height 

■ The use of standard symbols for integral , sum mat ion t etc. 
This in itself is novel only in the calculator world. How- 

ever^ die main challenge, which was felt not to have been 
met even by existing desktop systeniST was to come up with 
a consistent and intuitive way of producing and modifying 
these formatted displays as the user enters the expression, 
symbol by symbol. 

The most obvious limitation on the entry and display of 
mathematical expressions in the standard linear format is 
that when they get even moderately large, it becomes 
extremely difficult to survey the subexpression groupings 
visually and sort out all the parentheses. An expression like 

/(0.1/(X + Y).1/(1 + ((Z-1) 2 + X)),Z) 



is terribly tedious to read and mulerstand, compared to 



X+Y 



1 



(Z-1) +X 



dZD 



PAFETf PRDt HYP MATR VECTR EHSE 



This problem was especially onerous for the HP 28S 
FORM interface (renamed RULES in the HP 48SXJ, which 
applies operations like commutalton. association, and dis- 
tribution to subexpressions of a given expression. Locating 
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the desired subexpression (which ver\^ likely did not even 
fit on the screen) amid the plethora of parentheses, and 
recognizing i \s relation to the likewise messy and stretched- 
out resultt was too [iiuch for many users to bother with. In 
the HP 48SX, [he RULES interface is a subsystem of the 
Equation Writer, whk^h can be entered any time the expres- 
sion typed so far Is complete (a+b is complete, a-*- is not) by 
pressing the < key. This sends the cursor hack to the right- 
most object [number, variable, or operator) in the expres- 
sion, appearing as an inverse-video highlight of that object. 



X+Y 



1 



(Z-1) +X 



del 



RULES E&IT EUPR SUB REPL EKIT 



From here the highlight-eur^or can be moved around 
with the arrow keys. Pressing <. T results In: 



X+Y 



1 



dZ 



(Z-1) 3=^ 



RULES EI^IT EKPR SUt REPL EKIT 



The subexpression selected for an operation is that which 
is included in the range of a highlighted operator [if a 
vaJiable or number is highlighted, the subexpression sim- 
ply consists of that object alone). A menu key toggles 
between highlighting the individual object and the selected 
subexpression. 




This removes any remaining uncertainty about which 
subexpression is selected [although it is not usually needed 
because the grouping is so much more apparent, and more 
of the expression lends to fit on the screen). 

Since the subexpression selection mechanism was in- 
cluded for the RULES interface, it made sense to allow edit- 
ing of subexpressions as well. Once a subexpression is 
selected for editing, a command line is brought up in which 
to modify the subexpression in its normal string form. This 
is mainly useful for changing the spelling of a name or 
number. Other means of modi tying and combining expres- 



sions are provided by the SUB (substitute), REPL (replace) 
and RCL (recall) functions: the first sends a copy of the 
selected subexpression out to the data stack, the second 
replaces the selected subexpression with the algebraic 
object on the data stack, and the third inserts I he object 
from the stack in the cursor position when in entry mode 
(rectangular cursor showing). Of course, it is possible to 
back up u'jth the normal backspace key (|). 

Another problem with tlie standard linear format is 
remembering the meaning and order of multiple parame- 
ters. A frequent complaint about the HP 28S was that no 
one could remember how to type in the parameters to the 
INTEGRAL function. Did the lower or upper bound come 
first? Did one have to type the d that goes with the variable 
of integration? In the Equation Writer there can be no such 
confusion. Upon pressing the J key, one immediately sees 
an integral sign, with the cursor in the position of the lower 
bound. 




Any expression can be entered as the lower bound: it is 
terminated by the ^ keVr which is the general means of 
terminating any syntactic piece (exponent, numerator, 

denominator, etc.). The cursor then moves to the upper 
bound position. 




If one of the subexpressions grows vertically (e,g.. when 
entering a quotient tor the upper bound), the integral sign 
stretches to accommodate it. 




After the upper bound and integrand are terminated in 
turn, a d appears with the cursor to its right, making it 
obvious that a variable name is now required. 
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1 

B 



COS(fl)-Bdn 



Pl4RT.r PFiOE: HVP MATR VECTR E^ASE 



This IS a good place to mentioo another significant fea- 
ture of the EquaUoii Writer, which is its real-tiine S3mtax 
checking. With the cursor in the variable of integration 
position, the system will not accept any input except a 
legal vEuiabie nanie. Pressing + here will immediately 
result in the Invalid Syntax message, with the cursor returned 
to the left of the d. Similar behavior results from following 
a prefix function immediately with an infix function, and 
so forth. The EquationWriter uses the same internal parsing 
engine that is used to parse algebrai c express ions typed into 
the command line. All graphical events in the Equation- 
Writer (putting up a new symbol, inserting punctuation, 
altering the sizes of parts of the picture, and repositioning 
the cursor) are triggered by transitions across syntactic 
boundaries, as interpreted by the interna! parser. The ► key 
always has the meaning of ''go to the next s}Titactic posi- 
tion", so that it not onJy terminates exponents, denomina- 
tors, and so on. but also results in the insertion of any 
required token following the current position, such as a 
dosing parenthesis, or a comma if you are in the first argu- 
ment of a function requiring two or more arguments. If the 
current syntactic piece is not legally completed, the cursor 
will not advance. 

This general use of the ► key was actually quite contro- 
versial during the early phases of development, and this 
illustrates the challenge of coming up ivith an intuitive 
entry procedure, as mentioned above, One objection was 
that the ► key is an unnecessary nuisance when entering 
a typical polynomial: after typing the 2 in an expression 
like ax^-hbx + Cj why can't I just type + ? There was no 
probkm in adopting such a rule, based on operator prece- 
dence, hut I he result would be that the hated parentheses 
would start sprouting any time the exponent, numerator, 
denominator, or other expression was not typical (i.e., sim- 
ple), and the user would have to remember to type the 
parenthesis before starting the subexpression (just like in 
the old linear format). In the end it was decided to provide 
both methods as modes that can be toggled by the user. A 
similar problem with respect to division was solved by 
providing, in effect, two diiusion operators: one prefix 
(press A to initiate a complex numerator) and one infix 
(press -^ to draw a line under the preceding subexpression, 
going back to an operator of lower precedence than divi- 
sion). However, the uniformity' of the ► key has proven to 
be a contribution to an intuitive interface. Not only do all 
buiJt-in operators work similarly, but also all future 
operators, with their own distinctive graphical properties 
defined by users who write libraries, will also have the 
same feel. 

The ideal of displaying expressions just as they appear 



in textbooks turned out to be unattainable, mainly because 
textbooks w^ere found to follow different rules and ill- 
defined conventions. In the expression ax" ^ bx -;- c, every- 
one assumes that a and b are coefficients, but in general, 
variable names cannot be limited to one character, nor 
should there be something special about the letter x. Thus 
we gave up the idea of incorporating implied multiplication 
in the display. Howe\'er» it is present in the entr\' rules: 
typing 2A automatically creates the display 2'A, and simi- 
larly» any sequence of t%vo contiguous tokens functioning 
as operands results in the insertion of the multiplication 
symbol. The display is unambiguous, but the typing is 
simplified. 

Graphics and Plotting 

Scientists and engineers use graphics for many aspects 
of their work: describing problems* studying functions, 
working out solutions, presenting data, and so on. Our 
main goal for the H? 48SX graphics and plotting system 
was to offer plotting tools beyond those of the HP 26 S. 
which provided function plots and statistical scatter plots. 
We also wanted to contribute to the overall goal of making 
the calculator easier to use. A third goal was better integra- 
tion of graphics with other capabilities of the machine. 

Our design choices were based on feedback from HP ZSS 
userSt guidelines provided by the National Council of 
Teachers of Mathematics, consultations with mathematics 
educators, and the experience of team members as college 
instructors, mathematicians, physicists, and engineers. The 
result is the HP 48SX graphii;s and plotting system* which 
has the following nevv elements: 

■ A new RPL object type called a graphics object, or GROB. 
along with commands to create and modify GROBs 

■ An enhanced interactive environment for plotting and 
graphics 

■ Four new mathematical plot types and two new statisti- 
cal plot types. 

The HP 48SX uses a new object type called a graphics 
object, or GROB, to represent graphical images. Like all 
objects. GROBs can be placed on the stack, included in 
programs, stored in \fariables. and exchanged with other 
calculators. Most graphics commands act on the GROB 
stored in a special display region called PICT. The HP 28S 
used one tirea of memory for all displays. The addition of 
a separate graphics display area in the HP 48SX simplifies 
mixing graphics and stack operations* Both display areas 
are expandable, with scrolling available to view^ GROBs 
larger than the display. 

Commands are available to draw geometric shapes, 
sketch freehand, or do cut-and-paste operations with small- 
er GROBs, Most of these commands are available in both 
interactive and programmable forms. For example ^ geomet- 
ric shapes include boxes, circles, and lines: 
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Freehand sketches include arbitrary curves and indi- 
vidual pixels: 




The REPL (replace) command takes a GROB from Uie 
stack and pastes it into I he PICT GROB, The next example 
includes a label made from a string (by the ^G BOB com- 
mand) and a picture imported from a computer. 




Adding a modify step to cut-and-paste leads to a rudi- 
mentary but entertaining form of animal ion. 

The calculator itself uses GROBs for all display-related 
tasks. Graphic applications such as plotting use GROBs, of 
course^ but text must also be converted to pixels before it 
can be displayed. For example, the components of the nor- 
mal display (status information, stack objectSt command 
line, menu labels) are created as individual GROBs and 
then pasted onto the GROB in the stack display area^ Appli- 
cations such as EquationWriter and Matrix Writer similarly 
construct and combine GROBs. 

Much of the benefit of GROOs. like other object types, 
is in having standard tools for standard objects used by 
both the system and the user. This uniformity leads to 
smaller code with fewer defects. 

Ad example of the internal structure of a GROB can be 
seen in the PARTS menu label In the MATH menu. The cal- 
culator creates a small GROB for this label and then pastes 
that GROB onto the larger GROB for the whole display. 



€ HOME > 



4 
3 
2 
1 



PARTS PRDE: HYP MATR VECTR EASE 



The command-line form of this GROB is: 

GHOB 2 1 e E30000FFFFF1 1 B91 3 1 555BD 1 1 1 9BB1 D55B71 D55B91 FFFFF1 

where 21 and 8 are the width and height in pixels, and the 
hexadecimal digits represent the graphical data, starting 
left to right across the top row: 



E30000 

FFFFFT 

555BD1 

DS5S71 
DS5B91 

FFFFFI 



'mWfmi^m^wm m t^mkm 



'5*S-^ 



Each hexadecimal digit represents a horizontal sequence 
of four pixel St with the least-signiiicant hit representing 
the leftmost pixel. For example, the hexadecimal digil E, 
written as 11 10 in base two, represents four pixels: off, on. 
on, on. 

Each row is represented by an even number of hexadec- 
imal digits because the display hardw^are reads one b}1:e 
ftwo hexadecimal digits) at a time. This requires up to 
seven bits oi padding at the end oi each row: in this exam- 
plet three bits of padding are required. 

Function Plots 

Like the HP ZBS, I he HP 48SX uses the variables EQ 
(equation] and PPAR (plot parameters) to control plotting. 
The user can maintain multiple plotting environments by 
creating multiple directories, each with its own EQ and 
PPAB. When the user presses ^ PLOT, the plot application 
first shows the current equation (EQ] and plot type [one of 
the plot parameters): 



Plot 


'^x^\ 


je: 


FUNCTION 




EQ: 


5-2*X-"2+l/3' 




4: 










3: 










Z- 










1: 










IPLDTMPTYPEI 


NEH 


1 EDEC! 1 STEG 1 


CAT 1 



We first demonstrate the plot type FUNCTION, which is an 
enhanced form of the HP 28S plot type. Later we will show 
the results from other plot types. 
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The user can press NEW to name a new equation, EDEQ 
to edit the current equation, or CAT to show a catalog of 
equations: 



{ HDME > 



F2: 'Y^X-X-^Y' 
Fl: 'SIN<1/'X)' 
►EQ: 'X^3-2*X'^2+l/3' 



PLOTRSDLVR BCi* EDIT >$TK ViEN 



The equation specified by EQ can be an expression, an 
equation, a program that computes values, or the name of 
a variable that contains one of these. Multiple equations 
can be plotted simultaneously by combining them into a 
list and storing that list in EQ, 

After selecting the equation, the user can press PTYPE to 
change the plot tvpe. Other plot parameters control the 
plot*s scale and the placement and labeling of the axes. To 
change the other plot parameters, the user presses PLOTR: 



Plot type: FUNCTION 
EQ: 'X^3-2*X^2+l/3' 
Indep: 'X' 

X! -6.5 6.5 

y: -3,1 3.2 

i?jT;Hgi?ra?T?i rTTnniH;i;H iVii;Hi[;iiij-j 



Like the initial plot menu, the PLOTR menu displays the 
current values of relevant variables. To avoid interference 
with normal stack activity, these displays are maintained 
only as long as the commands in the menu are being used 
interactively, 

When the plot parameters are set, the user can press 
ERASE to clear PICT, or skip this step to superimpose the 
plot on the current PICT. The plotting is started by pressing 
DRAW or AUTO; the latter attempts to scale one or both axes 
automatically, according to the plot type. 

When the plot is completed, a menu of interactive oper- 
ations appears: 



-4~* — i— I — • — •^^r* 



R.i.isiha3.m[i??iiH»i>i?»»i iyj??i 



In the center of the display is a cross-shaped cursor, 
which the user moves by pressing the arrow keys. The 
cursor is used to specify locations for a variety of plotting 
and graphics operations. Pressing COORD causes a display 
of the cursor coordinates to replace the menu labels, if the 



PICT GROB is larger than the display, the user can force 
the display to scroll by moving the cursor off the edge of 
the display. 

If I he plot needs adjusting, the user can zoom in or out 
along either or both axes, or define a new center. If the 
plot is satisfacto^}^ the user can press FCN to show a menu 
of mathematical tools (applicable only to the FUNCTION plot 
type): 




RDDT (SECT $LDPE HREA EKTR EKIT 



With these tools the user can analyse the function with- 
out leaving the interactive graphics environment. For 
example, pressing ROOT invokes the solver to find the 
nearest root (the cursor moves to the root]: 



i I I i I — *T^^r* 



I I I I 



Pressing SLOPE invokes differentiation to find the denA^a- 
tlve at the cursor's location: 




Pressing EXTR invokes differentiation and the solver to 
find the nearest extremum (the cursor moves to the 
extremum): 




Pressing AREA (tvi^ice, with the cursor at each limit) 
invokes numerical integration: 
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AREA: -JfiSgSSOOOOOB 



When EQ contains of list of equations, the user can apply 
these tools to any mdividual equation, or use ISECT to find 
the intersection of any pair of neighbors In EQ, 

Other Plot Types 

To the HP 2SS plot types FUNCTION and SCATTER the HP 
48SX adds mathematical plot t\^es CONIC, POLAR. 
PARAMETRIC, and TRUTH, as well as the statistical plot types 
HISTOGRAM and BAR. The malhematical plot types share 
code for the hasic steps: setting up the plotting environ- 
ment, assigning successive values to the independent vari- 
able, evaluating EQ, plotting the corresponding points, 
cleaning up the environment, starting the interactive phase, 
and handling errors. Each math em a Heal plot type requires 
its own code to process EQ once at the start and to process 
each result of evaluation. 

CONIC plots handle circles, ellipses, parabolas, and 
hyperbolas. This type turned out to be a simple combina- 
tion of existing tools: the code underlying the command 
QUAD is used to turn EQ into two branches^ Then the code 
in the FUNCTION plot type that plots both sides of an equa- 
tion is used to plot both branches of EQ. For example, the 
equation 



4-X 2 9-Y"2-24-X-90'Y-225 



is plotted as: 





POLAR plots show the independent variable as a polar 
angle and the dependent variable as the radius. For exam- 
ple, the equation 



2-t1-COS(X}) 



is plotted as: 




PARAMETRIC plots show a complex-valued function of 
one real variable, where the reaj and imaginary parts are 
functions of the independent variable. For each point, the 
horizontal coordinate is given by the real part and the ver- 
tical coordinate by the imaginary part. For example, the 
equation 



T^2--T4i-(T"3-3-T) 



is plotted as: 




TRUTH plots show truth -valued functions oftw^oreal vari- 
ables. The location of each pixel represents the domain, 
and the value of the pixel represents the hmction value. 
Often the truth- valued function is the compost ion of a func- 
tion of interest, such as a real liniction of tuo variables or 
a complex function, and a projection function that maps 
function values to truth values. For example, consider a 
two-argument function. Plotting the expression 

(2*X'2-3*Y''2 + X'Y) MOD 16>B 

produces a contour plot of the polynomial with contour 
intervals of 8: 




A second example is a complex function* Plotting the 
expression 

SIGN (RE(Z 3-2'Z))= ^SIGN (IM(Z 3-2-Z)) 

where 2 is defined to be x + i-Y produces a quadrant plot of 
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the pohTiomiaL The black regioas are the points mapped 
to the first or third quadrants of the complex plane and 
the white regions are points mapped to the second or fourth 
quadiants. 
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HP Solve Equation Library Application 
Card 

The card contains a library of 31 5 equations, the periodic 
table of the elements, a constants library, a multiple 
equation solver, a finance application, and engineering 
utilities. 

by Eric L Vogel 



Historically; every hp programmable caU 
culator has had programs available iii somD form. 
There are application bookie with printed programs 
and keystroke sequences for machines like the HP 55, 25. 
:i3E. lie, and 32S. application pacs with programs on 
magnetic cards for the HP 65 and 67, and pacs with pro- 
grams in plug-in modules for the HP 41 and 71, These 
books and pacs foous on computation-intensive (as 
opposed to data-intensive] problem.^ in spec! fin science or 
engineering disciplines. Program size and capability are 
limited primarily by available memory and the single-line 
calculator display. 

The HP Solve Equation Library application card provides 
this capabiJity for the HP 48 SX scientific expandable cal- 
culatort but vvithnul the limitations of previous pacs. The 
focus on computation-intensive solutions is preserved, but 
for a wider range of disciplines than in individnal pacs in 



tlie past. An additionaJ focus on data-intensive applications 
has been added in the form of on-line^ electronic reference 
information (two thirds of the card contains data]. The 
12SK-byte memory capacity of the card makes these two 
emphases possible, and the large display allow^s improved 
user interfaces for the interactive applications. 

The card contains six major applications: 
■ Equation Library (Fig, 1)- This is the primary application 
for which the card ^vas named: a collection of 31 5 equa- 
tions organized in a catalog of 15 different subjects, each 
containing a catalog of equatior titles. For each title, the 
user can examine the equations and catalogs of names, 
descriptions, and tSI or English units for its variables^ A 
key contribution is pictures that desc:ribe the physical 
ailua[)ons represented by the equations. Our goal was 
that the subjectf title, and reference information would 
help a user select an equation to use with the HP Solve 



Equalions 



^^ 



H-^T 



h! H t^i^ 



M^?wir^?^ gn];igiii« rniaf^[a 



SI Units 



ft! h^2 

hi; u-u.v'2*K> 



Sublecfs 



EOUfiTIOH Liei^aRv 
Col(jrnn5 ^nd Beaws 
Eleztrieity 
Fluids 
Forces ^nd Eneroy 



Titles 



HERT TRAfiSFER 
Heat Capscity 
Thermal ExpansiOf^ 
Conduct ic«n 

ack eody Radiaticm 




Tc3 cold temperature 

h3; Cc^ri i ■^ct I'.'e cc'& f :-l 
_E3a EaEESa KMBgOailgll' 



Picture 




' — -^ -i- . --'l-^-y — ^e 



E!Iiai^£ld3B3ag2gI15^ 



English Units 



;MW|jIfeS^iiC B!Lu tiHiEi 03I1 



Rg, 1. Equation Ubrary user 
interface. 



22 HEWLFTT-f^ACKAfiD JOURNAL JUNE 1991 



)Copr. 1949-1998 Hewlett-Packard Co. 



application or the card's Multiple Equation Solver (dis- 
cussed below). 

Periodic Table fFig> 2). Tkis application contains all tiie 
chemical data (sucli as atomic weight and density) that 
appears on a standard periodic lahle of the elements. 
The primary' user interface is the universally recognlEed 
grid of elements. The user can m.ove a highlight block 
to see any element and its most-used properties on the 
grid. There is also a catalog of 23 propertie*; available 
for each of the 106 elements. Properties can be plotted 
versus atomic number to reinforce the relationship 
between propert^^ and atomic structure. A molecular 
weight calculator allows t_\^ing chemical formulas and 
quickly calculating their molecular weights. 
Constants Library, This is a collection of 39 commonly- 
used physical constants. These appear in catalogs of s\Tn- 
bois, descriptive names, values, and SI or English units. 
Multiple Equation Solver, This is a collection of com- 
mands that make it possible to use the Multiple Equation 
Solver to interact w^ith the user's own equations as a 
group, rather than just the groups of equations &om the 
Equation Library. 

Finance. This application duplicates the basic calcula- 
tions performed by HP financial calculators: time value 
of money (the relationship betvveen the number of pay- 
ments, interest rate, present value, payment, and future 
value) and amortization. 

Engineering Utilities, These are engineering functions 
that support the computational needs of some of the 
equations in the Equation Library. 
These applications come in two forms: interactive for 
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working with the a p pi i cation and its data, and noninterac- 
tive for programmatic calculations and access to the on-line 
data. 

Equation Library Evolution 

The Equation Library' concepi stemmed from three obser- 
vations. First p students need a wide variety' of sol ot ions 
because of the number of classes they take. Because appli- 
cation pacs are limited to specific areas, students often 
need several pacs to cover the different disciplines they 
study simultaneously. Second, most of the engineering 
applications for the HP 41 and its predecessors are pro* 
grams that simply solve an equation for a specific variable. 
More sophisticated programs of this typG allow inter- 
changeable solutions in which most or all of the nnknow^n 
variables can be calculated as long as they can be isolated 
algebraically in the equation. Some programs use iterative 
techniques to find a solution when an algebraic isolation 
is not possible. Later application pacs attempt to allow the 
user to select different units for the different variables. 

Third, the HP Solve application in the HP 48SX takes 
an equation and makes it into a smalls self-contained appli- 
cation. It solves for any variable given the others^ allows 
units to be specified for each variable, handles unit conver- 
sions automatically, and provides a consistent, straightfor- 
ward user interface for interacting with all the variables. 

From these three obscn^ations, we realised that we could 
create a collection of small applications in most of the 
science and engineering disciplines of previous application 
pacs by combining a collection of equations with HP Solve. 
The HP Solve user interface allows each application to 
w^ork the same way, and the ability to solve for any variable 
and automate unit conversions makes these applications 
more versatile than in previous application pacs. 

Interacting with Groups of Equations 

As the equutiun select it hi prpc:eeded, we found that 
rnlated equations were usually needed as a group, rather 
than independently (Fig, 3). While there are certainly 
Instances where only one of the aquations is needed* more 
often the entire set is used to find the value for a particular 
variable, Tn provide simplified access to related equations, 
we group them together under a single title, such as Linear 
Motion or Ohm's Law and Power, ralher than forcing the 
user to return lo the Equation Library to select each equa- 
tion individuallyn 

When we examined how a user typically interacts with 
a group of equations, we realized that the solution proce- 
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Fig. 2, PGffiQCliC Table user interface. 
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Fig, 3, EKampfes of common equatfon sets. 
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dure is straightforward, but gets tedious as the number of 
equations and variables gets large. Here is the manual pro- 
cess for finding all the variables for a set of equations given 
thai some of them are known: 

m Use the known variables to select an equation containing 
only one uriknowTi. 

■ Solve for the unknown, 

■ Add the variable just calculated to the set of known 
variables, 

■ Use the combined set of known and calculated variables 
to select another equation containing only one unknown. 

m Solve for the unknown, 

m Repeat this process until either all the unknowns have 

been found or as many unknowns as possible have been 

found from the given set of knowns. 

To make using the equations more straightforward, we 
have automated this manual seject-and-solve process by 
developing an extension to HP Solve called the Multiple 
Equation Solver [MES). The KiES selects the appropriate 
equation to solve based on w^hether it has one remaining 
unknown, and then solves for that unknown using the same 
numerical root finder used by the HP Solve application- It 
tracks the variables that have been solved for, and uses 
different equations to calculate other unknowns as soon 
as there is enough information available. 

The barrier to proper functioning of the MES was iden- 
tifying whether a variable is known or unknown. The exis- 
tence of the variable alone is not sufficient— after a solution 
has been determined, all the variables exist. The key under- 

Unknowns 
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lying principle is that the state of a variable (known or 
unknown] is independent of the value of the variable. The 
MES uses this state information to select the equations to 
be solved and the order in whiuh to solve them. 

Displaying Variable States 

The MES user interface is similar to that of HP Solve. A 
menu of variable names is displayed in the menu key area 
at the bottom of the display. The appearance of the menu 
keys is used to distinguish the MES state information. An 
extra key, ALL, appears at the end of the menu- 

Lnitially all the menu keys are white with black letters 
(like HP Solve), indicating that all of the variables are 
unknown [Fig. 4a). Typing a value and pressing a menu 
key stores the value in that variable and changes the key 
to black with white letters, indicating that the variable is 
known (Fig. 4h), 

Pressing the ALL key solves for all remaining variables, 
or as many as can be found from the given set of knowns. 

Messages appear during the solution identif%dng which 
variable is being solved for and its resulting value. After 
the solution has completed^ each variable retains its initial 
state. Correspondingly ► each menu key retains its initial 
appearance. Black keys (knowns) remain black, and white 
keys (unknow^ns) remain white. This simplifies solving a 
problem using the same knowns and unknowns but with 
different values. 

indicating Variable Relationships 

After a solution, some of the menu keys will have a small 
block in them to indicate the roles tiieir variables played 
in the solution (Fig. 4c). A block in a black key (known) 
indicates that the variable was used to find an unknown 
in a particular equation. A block in a w^hite key (unknowm) 
indicates a vahie was calculated for that variable during 
the solution. This represents a unique state for a variable- 
it is an unknown, yet it has a calculated vaiue. The next 
time this variable is solved for, this calculated value will 
be used as its initial guess. 

Pressing the shift key folio w^ed by a menu key solves for 
that specific variable, regardless of whether it is black or 
white [known or unknown). After a variable is solved for, 
its menu key is shown in white with a block to indicate 
an unknow^n that was solved for with a calculated value 
[Fig. 4d], Other menu keys may have blocks in them based 
on the roles their variables played in the solution. 

Solution Summary 

A summary of the solution prncedure is available by 
pressing the shift key toilowed by the ALL key [Fig- 5). This 
summary shows a catalog of each unknown that was found, 
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Its calcuiated value^ and the equatioa that was solved to 

liud it, in the order thai the imknowiis were detennined 
by the solution procredure. 
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Hardware Design of the HP 48SX Scientific 
Expandable Calculator 

Leveraging an earlier design resulted in prototypes with 
90% production tooled parts only nine months after the start 
of the project^ The HP 48SX includes an 8-line-by'22- 
character super-twisted nematic liquid crystal display, two 
expansion ports for R0!\4 or battery-backed RAf^ cards, 
and two t/0 ports: RS-232 and infrared. 

by Mark A. Smith, Lester S, Moore, Preston D. Brown, James P. Dickie, David L. Smith, Thomas B. 
Lindberg, and M. Jack Muranami 



THE NEEDS OF HP HANDHELD CALCULATOR cus- 
tomers—engineering, math, and sciencD students 
c'lnd busintjss and stjicnlifii: professionals—have rad- 
iCciUy changed over the ye^rs. os the personal compuler 
has het:onie the standard tool oF technical students and 
professionals. However, the need for convenient, handheld 
computation has not disappeared, hut simply evolved. 

Surveys of our high-enti UMihnicti! calculator customers 
reveal that nearly nil own or have access to a personal 
computer, that they use their calculator daily ^ thai profes- 
sionals make up ahoul half of the customers for high -end 
technical calcuhitnrs* and that they need a powerful hand- 
held calculator with graf)hit:s and 1/0 capabilities. The 
HP 48SX scientific expandahle calculator (see Fig. 1 on 
page E5) is designed to meet their needs for more advanced 
computation, graphics, custom izahility, expandability, and 
the ability In link \n their personal computers. 

The 64-row-by-131'Column STN LCD (super-twisted 
nematic liquid crystal display] provides the means for pre- 
senting the power of HP 48SX graphics, matrix manipula- 
tions < and equation entry. Two plug-in card slots provide 
RAM expansion [in :^2K-byte or 1 28K-bytc increments) and 
custom i:i!;ation (pi eg- in application ROMs such as HP's 
Equation Library ROM card described in the article on page 
22), A serial I/O port provides a means lo link to an IBM 
PC-compatible or Apple Macintosh computer, and an IR 
(infrared) port allows sharing c^t so lot ions between 



HP 48SX calculators and provides a link to the HP 82440B 
infrared printer. 

Previous Series Leveraged 

One tjf the primary prujei;t objectives for the HP 48SX 
was extensive leverage from the design and manulacttiring 




Fig. 1. Two expansion poii-:. d':^ijepl ROM of battery-backed 

RAM cards 
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development of our current calculator family to miniini^e 
deveJopment time and cost. Design leverage was a primary 
consideration in every HP 48SX part design. This emphasis 
an design leverage resulted in laboratory prototype units 
built with 90% production tooled parts only nine months 
after tbe start of the project. 

The HP 48SX is a direct descendant of the series of low- 
cost, high -volume, verticfil-format calculators introduced 
in lanuary 1988. This series, consisting of the HP 10, 14. 
17. 20. 21. 22, 27. 32. and 42 calculators, achieved lorn' 
cost and minima] part count through the use of a few highly 
integrated designs. These calculators were designed from 
the outset to be built on a highly automated assembly line 
at a rate of several calculators per minute. 

The designers of the HP 48SX leveraged many of the 
processes, materials, and even design details from the pre- 
vious series. As a result t the HP 4BSX is able to enjoy the 
benefits of an automated assembly line I hat could not have 
been justified by HP 48SX volume alone [see article, page 
40), Sixteen out of seventeen major assembly processes are 
common to both product lines. Only four parts are shared, 
but all raw materials and many suppliers are common to 
both families. A subtle benefit resulted from leveraging 
design details* since many design decisions were preor- 
dained .saving time during the investigation phase. By shar- 
ing details, tlie HP 48 SX designers were able In proceed 
more confidently, capitaJizing on the knowledge gained 
and improvements made as the earlier series of products 
entered production, 

Jt took some lime for tlie designers to accept leveraging 
compietely. because they were forced to compromise what 
they envisioned as optimum. Once the commitment was 
made, however, many unknowns were eliminated and it 
became clear that. In this case^ leveraging was the right 
way to meet the product and division objectives. 

Design Features 

The topcase of the HP 48SX is a four-color, injection 
molded part. Its 49 keys arc an integral part of the topcase: 
each key is attached and guided liy two small cantilevers. 
This design yields a low^-profile key with an excellent con- 
trolled feel. The keyboard is made of Mylar with tuned- 
resistance carbon graphite traces. This allows a low profile, 
reduces cost, and improves reliability because of tbe inert- 
ness of graphite. The battery contacts are engineered lo 
eliminate fretting corrosion and the loss of memory that 
w^ould inevitably result. The liquid cry^stal display is a 
super-twisted nematic (STN) design for improved contrast 
and viewing angle. Two expansion ports ac:cept ROM or 
battcry^-backcd Rj\M cards (Mg. 1). These cards are conve- 
niently sized to be handled easily and have a thin outline. 

Throughout the machine, from the generous radius of 
the bottom case ttiat allows it to fit comfortably in the hand, 
to the seven small openings in the battery compartment 
that pick off electrostatic discharges, details are incorpo- 
rated into the design of the HP 48SX to achieve small size, 
reliabilitv. and overall customer satisfaction. 

Initial Design 

Leveraging I he design from the previous calculator 
design resulted in less than optimal tooling and design 



options. 

For the simpler products, the layout of the single display 
driver IC on the opposite side of tbe printed circuit board 
from the dl.splay made sense. When applied to the HP 
48SX, this constraint forced the 202 outputs from three 
display drivers to feed through to the display side of the 
printed circuit board. This wasted a large amount of board 
area and caused the printed circuit board to be the most 
expensive non-IC component in the product. 

Initially, die mechanical layout was done around the 
same small button cell batteries that were used in the pre- 
vious series of calculators. However, electrical system 
simulations done early in the design cycle showed battery 
hfe to be unacceptable and the HP 48SX w^as redesigned 
around higher-r^apacity AAA batteries. 

Several other iterations occurred. A printed display win- 
dow was thrown out in favor of a special hard polarizer 
optically bonded lo the top surface of tbe LCD. This reduced 
cost, eliminated the window, which is easily scratched, 
and resolved a long-standing problem of particles trapped 
betw^cen the ivindow and display. The biggest benefit of 
the windowless design is the 67% reduction in glare. 

For a time we considered incorporating only one plug-in 
port. The two-port design was eventually selected to allow 
both ROM and RAM cards tube plugged in at the same time. 

Final Design 

The HP 48SX is manufactured from three subassemblies: 
the topcase, the printed circuit assembly » and the bottom 
case. These assemblies are built from 24 mechanical parts, 
four surface mount IHs, a IZfJ-pin TAB [tape automated 
bonding} IC, five discrete leaded components, and 31 sur- 
face mount devices [sec Kig. 2}. 

Topcase Assembly 

The topcase assembly is designed to be as free as possible 
of product-specific detail. This was done to allow the basic 
topcase assembly to be incorporated into future products* 

The top surface of the product consists primarily of a 
0.012-inch'thick. seven-color, printed aluminum overlay. 
The purpose of the overlav is threefold: (1 ) to [srrjvide^ a 
pleasing surface finish and shape, (2) to carry the nomen- 
clature for three shifted functions as well as the product 
name and number, and [3) to make the overlay the first 
line of defense in a carefully designed KSD (electrostatic 
discharge} protection system. Adding to the cosmetic 
appearance is an electro formed copper logo which, along 
with tbe overlay, is applied to the topcase using pressure- 
sensitive adhesive. 

The four-color molded topcase design represents a major 
engineering and process achievement. The HP 48SX key 
nomenclature is actually a .separate molded part for each 
key around w^hich the topcase is shot (see Fig. 3). To create 
the cavities that form the nomenclature, tbe legend artwork 
was digitized on a GAD/C^VM system. Cutter paths are gen- 
erated from this data. The cutter paths are used to cut a 
positive image of the nomenclature in a carbon electrode. 
The cutters used are special ground cutters as small as 
0.001 inch in diameter at the tip. The electrodes are used 
for electrodischarge machining of the extremely fine detail 
into the first-shot cavities. The tolerances must be carefully 
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Industrial Design of the HP 48SX Calculator 



The expressed needs and wants of high-end technical cal- 
ctilator users contributed to tlie design abjectwes for the HP 48SX 
scienfif^c expandadte calculator Needs analvsis and concept 
testing were conducted at the onset of the HP 4BSX program, 
and stated requ'^'ements included 

■ Handheld product shape (tiaditionaJ vertical fonnr^al) 

■ large display (8-Nne destrabte) 

m Customizable and expandable through ptug-in itwdia 
Data 1/0 for mass storage, printing, programming, etc. 
e High-qualiiy taclile keyboard, 

In addition to these stated requirements, the industriai design 
objectives for the HP 48SX included: 

■ Easily learned accessibility to functions and features through 
an organized keyboard and display interface 

■ Direct and easy access to expansion and customization media 

■ A visual and tactile experience consistent with the product s 
-next-generation" technological leadership. 

Package Design 

A softened, vertical -format package allows comfortable hand- 
tteld use of the HP 4SSX. Even the molded rubber feet are sculpt- 
ed to match the case contour for minimal tactile intrusion, Overall 
size was determined by the handheld requirement for width, 
keyboard and display size for length, and component sizes for 
thickness. Components are located to allow a low leading edge 
for the keyboard, resulting in a three-degree wedge profile The 
keys and key shapes are leveraged from the previous series of 
low-cost, high-volume calculators. They are designed to provide 
comfortable yet positive tactile response, minimal entry errors, 
and high reliability. User access to batteries and plug -in media 
Is provided through covers at the back of the calculator Both 
the infrared and RS'232 I/O ports are at the back, directed away 



from the user. A molded af row-shape indicalor on the topcase, 
above the logo, communicates the position of the direct ion -s^i^ 
sifJve irtf fared I/O feature, and the lens area of the cover over 
the infrared compcments is polished to communicate its light- 
transmfssive function. Nejct to it is the RS-232 port, which accepts 
a small, custom 4-pin plug designed to match the visual theme 
and scale of the HP 48SX. 

The goal of customization and expansion is accomplished 
through two plug-in slots for credit- card-size memory modules, 
available as RAM or ROM applications. The slots are located 
under a removable cover and infrared lens at the reer of the 
bottom case Because of cost and size constraints, an eject 
mechanism was not feasible for user removal of the cards. 
Instead, user access is provided by offset-stacking the cards to 
expose custom, molded plastic grips, which are attached to the 
cards by the vendor (see Fig 1 on page 25) These contoured, 
textured grips are molded with a hole in the center to provide 
visual access to a title graphic on the printed card surface while 
the card is inserted in the calculator. The constructed gnp texture 
is consistent in scale and appearance with other grip textures 
used on the HP 48SX, and enables the user to remove the cards 
from their fhctlon-fit edge connectors with a single finger or 
thumb 

A custom soft case was designed to be included with the HP 
48SX I ts objectives are to protect the product in normal transport, 
to provide storage for a quick- reference guide and additional 
memory cards, and to reinforce the message of product superior- 
ity and quality The final design is a fine-weave pouch, The case 
IS lined and padded, and has a zipper closure. An internal pockei 
is provided for the quick feference guide and memory cards . 

(continiued on page 2S) 
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User Interface Hardware Design 

Although Ihe HP 46SX approaches computer power and 
sophistication, it operates pnmarny as an application with a dedi- 
cated keyboard and display interface. The most signif lean! indus- 
trial design challenge was to provide visually ordered access to 
the 21 00 functions using only forty-nine keys plus display menus, 

The user interface surface of the HP 48SX is divided into two 
primary zones: the display and display bezel and the keyboard 
and keyboard overlay (see Fig. 1 on page 6) Tfie windowfess 
S-IJne liquid crystal display is framed by a formed aluminum 
overlay, which ^' cascades ^' down to ihe keyboard in two steps. 
Located in the middle step is a row of six keys which operate in 
conjunction with menus presented on the bottom row of the dis- 
play. The overlay color surrounding these keys is the same as 
Ihe display bezel to reinforce the association of keys with display 
menus. The six menu keys are differentiated in ssze and cofor 
from all other keys to distinguish them as special At the base 
of the second overlay cascade is the remainder of the keyboard, 
which provides qufck, direct access to afphanumenc entry, math 
operations, cursor control, and fund ion sets presented as display 
menus. The total of 49 keys was chosen based on the minimum 
number required to provide discrete alphanumeric entry. Keys 
are grouped and sized according to function and relative fre- 
quency of use to order the keyboard visually. 

The majority of the function markings are printed on the 
aluminum overlay. Unlike preceding modefs, including the HP 41 C, 
there was no oppori unity to ptace a second set of function mark- 
ings on ttie keys, This Is because of the leveraged keyboard 
design, which is limited to a single, integrally molded function 
marking. This presented a graphic challenge because the keys 
access up to four major functions each. As a result, the keyboard 
overlay is designed with up to two shifted functions above each 
key, positioned side by side and accessed by color-coded shift 
keys. The shift keys are also coded with arrows indicating left or 
right for the refative position of the shifted nomerTclature. These 
symbols are used in Ihe documentation in place of color to reduce 
printing costs Twenty-six keys also have an alpha character at 
the lower right corner, accessed by an alpha shift key. Siiifted 
functions that call up screen menus are distinguished by a black 



field behind the teKt and are grouped in two areas of the 
keyboard. The overlay has a total of six silk-screened colors and 
one tint. The keyboard is designed to accept snap-in custom 
overlays lor user- prog rammed keys, custom application require- 
ments, and so on. 

Colors 

A very dark, high-chroma brown called mercedes black was 
chosen tor the two major case parts for its consistency with the 
new calculator line and strong customer preference in earlier 
appearance tests. Because of the integral design of the hinged 
keys, they share the case color. A warm gray metallic color is 
used on the display bezel to feature the display area visually, 
soften the transition to the liquid crystal display, and add richness 
to the overall product appearance. The background color of the 
keyboard overlay is a tighter version of mercedes black called 
mercedes medium, which provides a subtle contrast to give the 
keys visual prominence. 

The most challenging colors to determine were the light blue 
and coral shift colors on the keyboard overlay.. The shift colors 
on all HP calculators are intended to contribute an accent color 
on otherwise neutral ptatfomis. and to code the product visually 
into a product category (business, scientific, or RPN scientific). 
The HP 4SSX is \r\ the scientific category, but functions in both 
algebraic and RPN modes and is really in a category of its own. 
The two shift colors selected were originally used for the two 
scientific categories, but are lightened lor readability. In addition 
to thesr both being "scientific" colors, they were setected because 
of their easily distinguishable hues and their balanced values 
and chroma wh^ch help alleviate a spotty appearance. All other 
function markings are in legend light gray, selected for its neu- 
tralily and readability on the background colors. 

Corporate tdentity is provided by a nickel-plated eieclroformed 
logo, selected for its high-quality, three-dimensional appearance. 
The produci name es designed for consistency in location and 
fonts wtth other current HP calculators, and is printed in a nickel 
metal tint to match the logo. 

Michael Derocher 

Senior induslriat Designer 

Corvallis Division 
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Fig, 3. A ■ -non-shot" photo of the HP4eSX keys. A separate 
molded pari for each key produces the key nomenclature. 
The topcase is molded around the key nomendBture. Notice 
the hole in the 9 key, which is formed by a moving core p\n. 
Thts hole allows the second-shot plastic (dark) to ftow Into 
the center ot ihe 9. 



controlled because the curved steel surface of the second- 
shot cavity must "shut off" ag^iinst the rjorresponding 
curved plastic nomenclature that was formed in the first- 
shot cavnty. The raised -plastic nomenclature ribs must be 
just touched by the second-shot cavity^ The interference 
between the two must be hirge enough to prevent the 
nomenclature from being pushed around by the injectior! 
pressure of the second-shot plastic but not sn large that the 
nomenclature plastic is crushed and distorted by the 
f:lamping force, which can be as high as 400 tons. 

The 49 keys are integrated inlo the topcase design to 
simpHfy assembly and eliminate the possibility of mislead- 
ing a key. To achieve good tactile feel, each key is sus- 
pended on two cantilevers, each 0.016 inch thick by QAW 
inch long. These small beams serve three iuirposes. They 
guide the key through ii we II -control led arc, they perma- 
nently attach the keytops to the topcase, and they serve as 
the paths through which the second-shot plastic ilows. To 
fill the keytops through these small beams, each key has 
Its own. gate, for a total of 60 gates. An ordinary part of 
this size would have only one gate. 

The Tnax material used for the topcase is a Nyloti-ABS 
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alloy and was specifically selected for its toughness and 
processing characteristics. The most critical aspect of the 
top case design is the small cantilever beams. The beams 
had to be tough enough to maiotaiji their mechanicaJ iBteg- 
nt>^ through environmental and life testing, yet supple 
enough not to degrade the force-deflection characteristics 
engineered into the snap domes. The Triax plastic was 
found to flow well, which allows a thin beam, and its 
toughness was verified in testing ov^er 2.5 million key cycles 
without failure. 

The tactile fee! of the keys is a result of painstaking 
design, testing, and quality assurance efforts. The 0.004- 
inch-thick Mylar dome sheet contains 49 details, which 
provide the snap feel as each key is depressed. Each key 
has an actuator which presses against the top center of the 
dome. As the dome is pressed it deflects at its hase into a 
dome spacer recess. At this stage the force is building 
linearly with deflection. As the force builds to the trip 
point the dome buckles, causing a sudden drop in force. 
Momentum and the resulting imbalance of force between 
the finger pushing on the key and the key no longer pushing 
hack causes tho inside of the dome to impact firmly against 
t he key bo a rd l: o nta ct s . The i n s i d e o f 1 h e d o m e is p ri n te d 
with a pad of conductive carbon graphitic. Upon si-vitch 
closure the dome pad shorts the inlerdigitated carbon 
graphite contact fingers of the keyboard. Below each key 
switch is another recess created by a O.OG3-inch-thick chas- 
sis spacer. This recess allows the keyboard to wrap around 
the depressed dome, resulting in a much more reliable area 
contact instead of the point contact of a dome sigainst a 
flat plane. 

The keyboard is a 0.003 -inch -thick Mylar sheet with 
screen-printed carbon graphite traces and contacts. The 
feedthroughs of the two-layer keyboard employ triple 
redundancy to improve yield and reliability. The keyboard 
lines are multiplexed with the address lines. This scheme 
reduces the pin count on the IC and saves printed circuit 
board area, both of which lower costs. However, it requires 
that key line resistance be carefully controlled. The exact 
sheet resistance of the carbon ink was measored/This Infor- 
mation was used to hand-tune the area of eat:h nf the 9B 
key lini^ traces. 

The backbone of the HP 40SX is the nickeTplated 0.018- 
inch-thick stainless steel chassis. The chassis serv^es several 
functions, the most obvious of which is to support the 
keyboard and add rigidity to the to pease. Sixty-two 
heatstakes clamp the keyboard between the top case and 
the chassis. The large number of heatstakes provides an 
even preload, which guarantees a consistent key feel 

The chassi.s rjlsn furnishes the negative battery t;ontact. 
Incorporating I he negative battery contact as an integral 
part of the chassis eliminated the need for a separate contact 
and the operations 1o attach it and its wire. The chassis 
serves as the connection between the overlay and the EST) 
shield located in the bottom t;asc. Redundant cantilever 
contacts are emplnyed in both cases to provide the lowest- 
impedance contact under all conditions. Seven soaps 
around the perimeter of the chassis maintain a constanl 
preload between the two case halves. This ensures a good 
cosmetic fit along the 0,n40-inch-wide saam. It also resists 
shear, greatly erdiancing the torsional dgidify of the prod- 



uct. A closed -ceil urethane foam pressure pad provides a 
constant force to maintain the connection between the key 
lines and the printed circuit board. The chassis provides 
the topcase with two snap details centered on the key line 
connections. These prevent the topcase from creeping over 
tinie under the constant force of the pressure pad in this 
area. A special detail is designed to stiffen the chassis 
around the liquid cr^^stal display. Basicaily. the chassis 
forms a frame around the glass display to protect it from 
impact and bending that occur as a result of the prodnct's 
being dropped. 

Two narrow strips of donble-sided adhesive tape are used 
to secure the display in the chassis. The 202 0.013-inch- 
wide LCD contact pads must be positioned within ±0.003 
inch to make proper connection to the printed circuit board. 
Two zebra connectors are nsed to make connection between 
the LCD and the printed circuit hoard. The ^ehra connectors 
consist of tw^o strips of silicon rubber supporting a thin 
row of alternating conductive (carbon loaded silicon) and 
insulating materials. The conductors are on a 0.004-inch 
pitch so that each display line connection is made with a 
minimum of two conductors. Two precision punched 
holes, which are optically registered to the printed circuit 
t>oard traces, align the chassis/LCD assembly. Tabs on the 
chassis are inserted into the zero- clearance printed circuit 
board holes, permanently alllgning the printed circnit 
board and LCD. Six twist tabs secure the assembly, provid- 
ing a constant preload for the 2ebra connectors. 

The eight-line, twenty-two character graphics display is 
one of the HP 48SX's most valued features. Attempting to 
prevent display breakage when the product was drop tested 
from up to two meters was one of the more interesting 
challenges for the designers. 

The glass from which liquid crystal displays are man- 
ufactured is fragile. Glass failures are always in tension. 
The glass has a theoretical tensile strength of 100,000 psi. 
However, flaws within the glass lower its design limit to 
10.000 psi. Edge defects, a result of scribing and breaking 
the glass to size* cause stress risers which further reduce 
Its usable strength to only 1 ,000 psi. Once the design of 
the display mounting liad been optimized, designers turned 
to reducing the variabiflty in the strength of the display 
itself. Improving the surface finish at the scribed edge 
proved to be the most attractive solution. The display in 
the HP 48SX has a special polished finish on the glass edge 
where the tensile stress is highest during a front drop. This 
results in measurably better and more consistent drop test 
performance. 

Printed Circuit Assembly 

The HP 48 SX printed circuit assembly is a collection of 
proven technology and innovation. To be built on the exist- 
ing surface mount printed circuit assembly line, both of 
the nmv HP 4BSX connectors had to be designed as robot- 
loadable surface mount devices. 

Dominating the printed circuit assembly is the large 80- 
pin plug-In card connector. This custom connector accepts 
two cards in a staggered formation so that the label on each 
cnrd can he seen. Thti card conoector is molded with 40% 
glass fillf:!d PPS to <jurvive the 22 5X (437^F) infrared solder- 
ing process, Heatsttikes are used to secure the card connec- 
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HP 48SX Custom Integrated Circuit 



The HP 1LT8 fC is the single custom chip in {he HP 4SSX 

caiGuiator. The 1LT8 IC is divided into the following functional 

areas 

« A 4-bit CPiJ WFth an 8-MHz clock. The 1LT8 CPU is identical 
\o the CPU used in the HP 29S. which ss a leveraged redesign 
of the 1LK7 CPU, The ILTB CPU provides faster instruction 
execution limes but slHI maintains ful! compatibility with Ihe 
1 LF2/'1 LK7 and the HP 71 B bus archiieciure. The CPU intemal 
and external data paths are 4 bits wide. Memory is accessed 
In 4-bit quantities (referred to as nibbles) using 20-bit address- 
es^ yielding a physical address space of 51 2K bytes. The CPU 
intemal word size is 64 bits. Operations are performed on data 
strings up to 16 nibbles in length. 

■ A memory contioHer capable of interfacing to five commercial 
byte-wide RAMs. ROMs, or plug- in ports. The purpose of the 
memory rnterface is lo allow the l LTS chip to drive commercial 
RAM and ROM ICs. Since commercial memory parts are byte- 
wide, thjs requires some careful interfacing to the 4-bit world 
of the CPU. The same lines thai go to the memory address 
are also used to scan the Keyboard. The keyboard is con- 
nected through series resistors to the l,/0 lines while the mem-. 
ory is connected directly. This allows commercial memory ICs 
to be connected lo the 1 LTS chip with a minimum of added 



pads. Each memory device can be configured by software to 
the required size and placement in the address space. 

■ A liquid crystal display (LCD) controller capable of driving a 
64-way multiplexed display This controller halts the CPU to 
access data in main RAW and then formats it for the LCD. It 
is capable of handling the softkeys in a separate memory area 
and scrolling the main display. 

» A collection of memory mapped control registers including a 
32-bit quartz-cry sial-controlied timer, a 1200-Eo-9600-baud 
tult-duplex UART capable of dnving RS-232 or infrared-level 
signals, and a cyclic redundancy check (CRC) generator 

■ A collection of analog circuilry including a dual power supply 
(4.3 volts for the system and 8.5 volts for the display), a low-bal- 
tery indicator, a power-on/reset circuit, a crystal oscillator, a 
frequency multiplier (which generates the 6-MHz CPU clock 
from the 32-kHz crystal), and a display voltage generator 
The 1LT8 IC is manufactured at the Northwest IC Division of 

Hewlett -Packard. 

Preston D. Brown 

Development Engineer 
Corvallis Division 



tor to the printed circuit board and to take the preload 
exerted by the 80 cantilevered contacts. The contacts con- 
sist of two rovvs of cantilevered phosphor bronze beams 
which lire sngled into the solder paste to form a bull foinl. 
A butt joint is used because it wicks the solder up high 
into a fillet, preventing solder bridging between adjacent 
leads and allowing easier inspection. The nominal preload 
between the leads and the jilane of the prmted circuit board 
allows for some nonplanarify In the leads, ensuring ihal 
each lead penetrates the 0.004-inch-thick solder paste and 
yields a well-wetted solder pint- 

The four-pin serial connector uses a similar butt type 
solder joint design. Like the card connector, it is a custom 
design using heatstakes to fixture the part during infrared 
soldering and lo prevent the solder joints horn being over- 
stressed during use. Gantilevered arms are formed with the 
body of the connector to provide a slight snap upon inser- 
tion of the plug and a retention force to resist removal. 

The most intensively engineered component on the 
printed circuit board is the 170-pin TAB-package IC. The 
capabilities of the IC itself are very impressive, but equally 
impressive is the way in which the IC is connected. Gold 
bumps are deposited on the IC at each contact pad, A circuit 
consisting of 0.003 -inch-thick poiyimide film with 0.003- 
inch- wide traces is positioned on top of the IC, The layout 
of the circuit is such that the traces al the inner portion of 
the tape actually cantilever off the poiyimide substrate. 
These tin-plated copper beams are then aligned with the 
IC and simultaneously bonded- 170 inner lead bonds with 
a 0.005 -inch pilch are made in one operation. The advan- 
tages of TAB are that its pin count is high, that it can be 
gang bonded, and that the poiyimide substrate is punched 
witli holes for 3 5 -mm sprockets just like 35-mm move film 
(see Fig. 3 on page 42)- The last feature is used to place 
hundreds of parts with no human intervention. The reels 



of burned -in and tested TAB packages are loaded onto an 
HP-developed TAB dispensing tool- This tool trims and 
forms the outer leads and presents the excised parts to a 
robot for placement on the printed circuit board. 

The pitch of the outer leads is 0.020 inch, so accurate 
positioning of the TAB package nn the printed circuit board 
is important. The position of the printed circuit board traces 
is determined by reading a target on the board with an 
optical sensor mounted on the robot. The I'AB package is 
positioned by an annular ring of copper trace which over- 
hangs a hole in the poiyimide. The hole is exposed and 
etched at the same time as the 170 leads that are being 
positioned. This allows very accurate positioning of the 
lends using a simple mechanical dctaih The leads are 
formed so they are preloaded into the solder paste. They 
have some compliance but the force they exert requires a 
TAB clamp to maintain the leads in Intimate contact with 
the paste during the retlow operation. The steep angle at 
which the leads untrrjr the paste is designed to hold the 
solder np high into a fillet, easing inspection and prevent- 
ing solder bridging tietween pads. 

Much design and testing went into the development of 
the TAB process. The results from a technical point of view 
far exceed all expectations. 

Bottom Case Assembly 

Most of the details unique to the HP 46SX are contained 
witliin tlie bottom case, making it possible for future prod- 
ucts to use the HP 48SX topcase assembly. 

The HP 48SX's plug-in cards are guided into the card 
connector through the rear of the bottom case. A box is 
created withhi the bottom case to guide the cards and pre- 
vent damage to internal components. Aninfrarcd-transmis- 
sive polycarbonate card door covers this box, keeping the 
cards from dislodging during a drop and forming a window 
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over the LED and photo transistor used for infrared I/O. 

Critical to a CMOS product is maintaining power to avoid 
losing memory. Particular attention was paid to designing 
the battery compartment so power could not be interrupted. 
The batter}' compartment holds three AAA batteries* The 
compartment is designed so that if batten^ leakage occurs 
from the vents at the negative terminals, no openings allow 
it into the drcuit board. The battery contacts are designed 
to prevent frettiTig corrosion, a type of corrosion caused by 
micromotions at the contact point, which results in oxide 
buildup and eventual loss of contact. Extensive testing was 
undertaken at the very start of the project to characterize 
this phenomenon. Custom electrical measurement tools 
were employed that could detect the very onset of fretting 
corrosion. Batteries from U.S., European, and Japanese 
suppliers were exhaustively tested for compatibility with 
the contacts. Even the battery door was designed to prevent 
loss of power. The door employs a multistage snap, which 
prevents the batteries from becoming dislodged in drops 
up to two meters. The result is a design that ensures 
extremely reliable power even under the most extreme con- 
ditions, 

A 0,OOB-inch-thick 3003 HI 8 aluminum ESD shield lines 
the inside of the bottom case. The shield contacts the chas- 
sis with a large-area contact. This forms a two-dimensional 
Faraday cage, protecting the circuitry from exposure to 
electric fields. The HP 48SX is designed to withstand 
repeated discharges with potentials up to 25 thousand volts 
while running without hard failures, and 1 5 thousand volts 
without any disruption of its operation, The ESD shield 
also provides the ground connection for the piescoelectric 
beeper. A single spring makes the posittve connection and 
provides the force for the ground connection to the ESD 
shield. Heat stakes keep the beeper and ESD shield in place. 
The conical beeper spring is designed with three closed 
coils at the top and bottom. These coils are wider than the 
pitch between the open coils, preventing the springs from 
tangling so they can be barrel plated and vibratory -bowl-fed 
to a robot for totally automated placement directly on the 
printed circuit board. 

Completing the HP 48SX package are four molded feet, 
which are sculptured to conform to the bottom case radius. 
The feet are press fit into the bottom case while it is still 
warm at the molding machine. A small bump on each foot 




provides compliance so that the HP48SX will resist rocking 
even if the surface is slightly uneven. 

Electrical System 

The HP 48SX electrical s>' stem is considerably more pow- 
erful and more complex than those of previous HP hand- 
held calculators. With its infrared and RS-232 1/0 and plug- 
in ports, it is also more versatile. The heart of the electrical 
system is the 1LT8 chip, a 170-pm HP-developed IC (see 
boXt page 30). 

The HP 48 SX contains two printed circuit boards. The 
main logic board is sandwiched between the topcase assem- 
bly ^Ttd the bottom case. The Mylar domed keyboard with 
carbon graphite traces is housed in the topcase assembly. 

The 49-key keyboard is scanned by the 1LT8 chip via 
mullipiexed RAM and ROM address hnes. Address lines 
A9 to A17 scan the keyboard while AO to A5 are inputs to 
the 1LT8. The keyboard is read asynchronously every milli- 
second when the CPU drives its output register lines, A9 
to A17, all high and reads Hs input register lines, AO to AS. 
W'hen a key Is pressed, contact is made between an input 
register luie and an output register line, putting a high level 
on the input register line. This high level generates an 
interrupt, causing software to scan the keyboard to deter- 
mine wliich key is pressed. The ON key is not scanned but 
is wired to V^q. This allows the system to be turned on 
while in deep sleep. The ON key is the only key capable 
of generating an interrupt and waking the system up. All 
key lines ;ire tso kited from the main system address lines 
by built-in 4-kn carbon graphite resistors. 

The logic board contains five ICs: a 256K-byte ROM. a 32K- 
byte RAM, two column drivers and the 1LT8, which con- 
tain s t h e GP IJ . an LC D d i i v er c o n t ro 1 1 e r , a memo ry co n I ro I - 
ler, and a UART for Rfi-232 and IR I/O control. Also on 
the logic board are 36 discrete components, two 40- pin 
card connectors (for plug-in cards), one four-pin RS-232 
connector, 202 pads for connection to the display, and 17 
pads for keyboard contact. All of tins is on a printed cin;uit 
board that measures 5.1 inches by 2.75 inches [see Fig. 4). 

During product development, three logic boards were 
designed: the 2 5 OK ROM version that was released to pro- 
duction, a 32K OTP* EPKOM version thai contained self- 
test code used for initial shakedown and environmental 
testing, and a 250K EPROM version that was used for soft- 
ware development ^ debugging, and quality assurance. 

For production testing. 77 logic board I races have dual 
test points. These test points are probed by a special test 
block that is connected to an HP 3005 test system. The HP 
3065 tests all discrete components and ICs before the unit 
goes to final assembly. 

The system is powered by three AAA batteries and has 
three power supplies, which are controlled by the 1LT8 
chip. The V„ (8.1 to 8.9V) supply is used for the LCD 
display and RS-232 voltage swings. V^n (4.1 to 4-5V) is the 
main logic supply. The Vf^n (4.1 to 4.5V) supply is derived 
from the Vpj^ supply and is used to power the ROM and 
plug-in cards. 

The power supply requires only two discrete diodes, an 
inductor, an n-channel power MOSFET, £ind three filter 



Fig. 4. HP 4BSX fog!C pnnted arcuit assembly. 



'DTP Qne-titTie program me b^e 



JUNE 1991 HEWLETT-PACKARD JOURF^AL 31 



)Copr. 1949-1998 Hewlett-Packard Co. 













4 i:-- 




1^ 




.i.... v.-^-v,..^ 1 




[ 




ja f I«iui03~ 


"syye^ A 'F-XT^i* **^^^- f^^^s^*^-- 




UOISJ3A 


ipuKjja 


4yauj30 


AjieLKi 


Ain^uon 


tiUO J 


>iE.Bl )£tii£«J 


J3P 


ixis iLio :>/;; 1 J s;i.j t^q t>j- 








X0| t)Ji?M]jas cfr3[i>\;ip rq "^"^^Q os^n fu ]tjirv^ s.ir»s]i \uew 
iu3tjua6eue^ uoi)ejn6yaoo snoau^BojdtaH 



iiOf|ijnSt|uoo 
punog 



MfJSJcn 




uisisAs o|}Qdv 



ajsei] p3Jii^S:i03; ? ^1 XI NH. 

,UBJi|qj(? HI? SI a|nj 

jspq joj dn:tas t)i{i 
:{:t uo pesBq aiF jtiqi 

joj;Ejd onody-noa 



y[ni[;iuj ujj^jsjVs puE sfoo^ jo ias guibs aip esn spijn^ [p l^^MI 
sajasa^ HldSG '^lU ^^Jpi^^i^ ^qi '^^1 A:3utj|fi[SLiG^u! Xq pa^nBD 
lue^qojd e UAiop ^dtiii o} ^^s^m ^y{U\ jqHiui ]] ^syoipis jo 
uoTpBffOD AJBi|iqjB tiB q^tM pa|tduio:) SI ajqBinDaxa ub jj 

jeHRii^d in qitiq s| |[ 
LK?q,\\ sjnoq zt o; sjnoq oe luojj Kdojp einis is£)i uoiitipiieA 
ypY aqj uiu oi lamii aqi 'aidniBXs loj^ *jeiiUB:tsqns »9q ue:} 
iurpirnq pifBJ^d Aq papiAOjd luaitiBAO^dtut a^oi^uuajjed 
tjqX ■&'aLL;qr}Biii jbioabs no Stnimnj Kp(fnq [r-tfjEjed SA^uqs 9 
'81 J ^^^ujqDnm papB(j| Af]qSf[ ]soiu m\] uo splfoq siio^s pue 
*s'ia in d 010:3 Plfnq i^tepipum) jo uoi^ezqim QcIJ ^41 s^^Jt?j| 
HaSQ *^ui[i Buws aqi >B jainduioD ojiody aao uBqi atom uo 
§ijjp|inq |a||BJBd joj jJodduH pappy 33SQ P f- uoTSia/\ 

xy iiqi snjd 's^iq suibs aqi pjniqjaj 
uwa apoj aqi §uiiit?df4j jaaotoLia aqi 'jaiBj sje3A oa\) 3nq 
B podai sJamoiKn:) utsqM 'aiTqeaj siq^ q^A\ '^uBiSoid oqi 
dn a^Bui ]Bq; (apoui maisA's piie *s|oo^ 'ss^jnos 'saiJT3U|q 
'Kpeejqi uoijRjntfipicjLi punoq oi]] ]o loqsdBUK ]uauBuu^{I jo 
'9S!3a[aj P^ i^^iim ub:: Ji>sn aq; ■ potJ3nqop pue qniq ai ujvijSiajd 
£*qi ja\|V "^^Ji^-iqil SIT p ino Ajpajip iuemap HHSG H^^^ 
|o U0JSJ9A poiisop aqj spesj 11 'sa^niiaxa |du:3S uotjEjSui^ii 
s^JtJsn aqi sy ^sopuapiiadapjaiut Jpqi Oi BuipjODDB spjmq 
pajinbai aq; sa^nanba^ w Sirqqinq spnis g^ga aiojag 

o} SBq ;r s:>[Lqq:[ 
33SG uaqM pyrnq o; pu io *pnnq b joj ||E3 ^^useop pBajq^ 
LroT;BjnSijuOD punoq aqi qSnoq] uaAO pjinqai o\ 33SQ 
aojoj UBO jassTi aq:| qniqAi qSnojq:| siusiuBq^aiu apujaAO 
os[E ajE aiaqx 'Sfopom eq; p^mqaj ^ou ||]a^ i\ laq pasn 
SEW uofs^jaA aojnos jo uoijdo ja[tduio:j joqM pjoiiaj |[l\\ 
133SQ 'saSiTBqD ADHapnadap potiutjuou e jj ■3[npora aq^ 
p[mqai qi.w ggsQ 's?aoueq:i Anoapuadap |bot;tjo b j; ^edt 



:!:;:a 















©Copf. 19^0 1008 H ow l ott Paokard 
, 



O.OSO-tnch pitc^. Towards the memory card, ttie pms are gold- 
plated and cantilevered to provide a contac! force of 30 grams 
to 70 grams each. Towards the HP 48SX pririted circuit board 
the contacts are soider-piaied and terminate in either a vertical 
or SS^-off-vertica) surface mourit butt jotm S^nce the two memory 
cards can share ail but five pins, 35 pairs of p^ns are sotdered 
to or>e printed circuit board pad each The two copper ground 
pins, wh^ch are press fit into the body, push open the meniory 
card shutter and provide a path for ESD from ihe card panels 
directty to the printed circijit board ground plane. The 40% glass 
PPS alignment comb is press fit onto the body after aH 80 pins 
are inserted and formed, providing alignment of the pin tips onto 
the pnnted circuit board pads 

Overall, the connector measures 2.378 Inches wide by 1 .555 
inches long and stands 0.556 incn oft the printed circuit board 
Although two cards are held stacked, the custom connector is 
less ihan 1 5 times the thickness of the manufacturer s original 
single-card connector. 

While design details pertaining to body strength, pin geometry, 
and pin plating were adapted from the original connector, the 
healsEaking process to which the HP 4SSX memory card connec- 
tor had to conform was a challenge Basically, after insertion 
through the printed circuii board, the heatstake pins are flattened 
using temperature and pressure, thus preventing removal The 
flattened portion, called the heatstake "head", consists of very 
rigid and brittle glass fibers in a matrix of remelted PPS The 
head must not deform under the force of the 80 preloaded contact 
ptns during reflow soldering, or solder defects wiil result from 
lifted pin tips. In addition, the head must be tough enough to 
endure repeated shear stress during card insertion testing and 
repeated lenslle stress duhng drop testing. To complicate mat- 
ters further, the heater blocK on the printed circuit board assembly 
fine needed to heatstake the memory card connector, serial con- 
nector, and TAB clamp simultaneously to minimize cycle time. 
To establish optimum heatstake head geometry, heater block 
pressure, heater temperature, and melt time, repeated staking 



ar>d subsequent drop testing were conducted initialty. ten stakes 
of 0-062- fnch diameief were used but proved to be brittle in drop 
testing Next the stake diameter was increased to 118 inch 
but the resulting force imbalance on the heater block caused 
the'^sena^ connector heads to be loose After much trial and error, 
the combination of four 01 18-trich-diameter heaistakes. a 1 47- 
tnch head dtameter a 440^ healer temDerature. and a 13-S8C- 
ono melt tsmie produced - e heads 

The memory card cori; -^ "ed combines ttie 

benefit of the manufacturers proven oesgn wtih custom details 
rncofporatedto produce the bighest-perlomiance part using pre- 
detennined assembty processes. 

Performance 

Tests proved the memory card and connector forthe HP 48SX 
tested be a reliable combination, No functional problems devel- 
oped after 20.000 cycles of Knsertion/removal life testing consist- 
ing of 1000-insertion sequences alternating with 24'hour periods 

in a supersoak chamber. The card survived one-meter drop test- 
ing, both alone and plugged into the calculator, as did the con- 
nector The card also experienced no mechanical damage when 
exposed to 25.000-volt ESD, both alone and plugged in. 

Conclusion 

The goals of design and manufacturing leverage were met by 
using an OEM memory card and incorporating off-the-shelf con- 
nector design details where applicable Custom features were 
added, however, when increased reliability and manufaclurabllity 
were deemed necessary_ Thus the best solution for both cus- 
tomer and project was implemented in the HP 48SX memory 
card and connector, 

M. Jack Muranami 

Mechanical Engineer 
Corvailis Division 



capacitors [see Fig, 5]. This is a boost-switching pov^^er 
supply in which the 1LT8 chip controls the current in an 
inductor, which is connected to the batteries, via the MGS- 
FET. When one of the supplies (Vn or Vnn) is tow. the 
ILTB pulses the MOSFET at a 122.84-kHz rate, increasing 
the inductor current. The current from the inductor is then 
dumped through one of the diodes, charging its filter 
capacitor- If both supplies are low the iLTfi switches the 
charge between them at a 30,72-kliz rate. 

To conserve battery life, the power supplies (and the 
product) have three modes of operation: 



ih¥ 




iLiecpycNp 



'4 
I 

Vpp ♦►Vh 



2^CR, 1> Va^r 



1 jr^^tTT^^l. 

S^ =r — 1.2 mH J {5 



1000 fiF I 



33 ^F °' 



1 <aw o X 



AAA 
(3) 



5.6V 



Fig. 5. HP '^8SX power supply schematfc diagram. 



■ Running. The 1LT8, column drivers. RAM and ROM, 
power suppliev<5. and plug-in ports are all powered. Bat* 
tery current is 9 mA. 

■ Light sleep. In this mode tht^ 1LT8 turns off and battery 
current drops to 4 mA. This mode is entered whenever 
the CPU is inactive and a key is not being pressed. The 
1 LT8's display controller accesses memory every 244 fin 
to update the display. When the update is complete, the 
address Hues switch and check to see if a key is pressed. 
Pressing any key will turn the CPU on. 

■ Deep sleep. All supplies are turned off and battery cur- 
rent drops to 12 ^A. The Vod supply floats to the battery 
volt age (Vy^^-jl which supplies power to the ON key, 1LT8. 
and RAM. This mode is entered when the CPU has been 
inactive for ten minutes or the unit has been turned off. 
To wake the system, the ON key must be pressed. 

The 1LT8 chip also monitors the battery voltage. When 
the voltage falls to between 3-4 and 3,0 volts, the low-bat- 
tery annunciator is turned on. If the batteries are not 
changed and the battery voltage falls below 1 .5 volts, tke 
sy.5tem turns of!'. A 1000-^tF capacitor maintains the V^d 
supply for several minutes while the batteries are being 
changed. 

The 64-row-by-131-column STN LCD is driven by two 
commercial column drivers, each driving 64 columns, and 
the 1LT8 which drives 64 rows^ li columns, and 7 annun- 
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ciator lines. The t^nJuraii drivers receive their data, liming 
and control signals, and voltage levels from the 1LT8, One 
of the prDbtems with the commercial column drivers is 
that tliey require a negative voltage. To overcome thi.s. we 
connect their ^ V line to our V^ ( + 8.5V} supply, their GND 
^^ ^''oD { + 4.4V) and their negative supply to GND, This 
requires all data and control .signals received from the 1LT8 
to swing h^om 4.4V to 8.5V. Display data is stored in system 
RAM, and the 1LT8 display controller interrupts the CPU 
for 22 to 23 ^ every 244 jjls to access it. As display data 
is received, it is serially shifted to the column drivers. 
When the column drivers have received 128 bits of datan 
they store it and output it to the display synchronously 
with a row driver output from the 1LT8. 

For ease of expanding the HP 48SX's capahilities, dual 
40 -pin connectors are installed on the logic l:)oaid. These 
connectors will accept credit-card-size |)hig-in RAM or 
ROM cards. Each connector has its own chip select line but 
all address and data lines axe common to the internal ICs, 
Each connector can accept up to 128K bytes of memory. 

Thf? 1LT8 tests the connectors to determine if a card is 
presenl and if it is write protected. It does this by checking 
the card's write protect output. If the write protect signal 
is high, a card is plugged in and can be written to (RAM). 
If the output is low- o card Is present and is write protected 
[Rj\iVI or ROM], If the line is floating, no card is presenl. 

RAM cards have their own lithiuni keep-alive batteries. 
When the HP 48SX goes into deep sleep, the power supply 
to the cards {V^q supply) is turned off- When the supply 
drops to between 3.9 and 3.5V, the RAM switches to Its 
internal battery. The lithium voltage is sampled by I he 
1 LT8, and when it drops to between 2-5 and 2.2V, a lo w -bat- 
ter v annunciator is turned on» 
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The HP 48SX Calculator Input/Output 
System 

fldi RS-232 link allows communication with personal 
computers. An infrared link provides for printing and for 
two-way calculator-to-calculator communication. 

by Steven L. Harper and Robert S, Worsley 



WHEN HANDHELD CALCULATORS were first 
introduced m the early 1970s, they provided por- 
table computation without much memory. The 
limited keyboard and one-line numeric display provided 
just about all the Input/output needed to use this capability 
effectively. As the incorporation of advancing memory 
technology made possible the storage of larger amounts of 
data and e%'fin programs created by the user in these handy 
little machines, the keyboard and display became an intol- 
erable bottleneck. The need to enter a thousand or so key- 
strokes manually to use a program that someone else has 
written is quite an effective barrier. 

The first solution to this problem was to use small mag- 
netic cards to store the data and programs. There were 
some difficulties with power consumption, physical size, 
mechanical %vear and tear, and cleanliness, but this mode 
of input/output was the accepted standard for some tlme^ 
Eventually, however, larger and larger memories began to 
outstrip the capacity of the cards. This, combined with a 
need to communicate with other types of devicies thai did 
not use magnetic cards, necessitated a new approach. 

The HP-IL (Hewlett-Packard Interface Link) was an elec- 
tronic interfacing system that was designed with the needs 
of calculators in mind- It allowed systems with several 
devices to be configured automatically and controlled by 
a calculator. These devices included printers, mass storage^ 
adapters to other interface systems, and even instruments- 
In many ways, it was superior to existing electrnnic inter- 
faces* but this was not sufficient to overcome the inertia 
of the massive installed base of these other de\dces, Prices 
of calculators continued to drop and patterns of use 
changed as personal computers became ubiquitous. For 
these and other largely nontechnical roHSOiis, HP-IL was 
no longer the ideal input/output medium for the majority 
of HP calculator users, 

One area of serious complaint with calculators and elec- 
tronic interfaces had been the cost and inconvenience of 
the cables. In addition, some calculators were so thin that 
even the HP-IL connectors* designed for small size, were 
unacceptably large. The most pressing need for these 
machines was to provide some form of hard-copy output 
to a low-cost portable printer. Drawing upon technology 
similar to that used in infrared remote control of TVs and 
VCRs. HP introduced a printer and a line of calculators 
that met the basic need with an interface that gave custom- 
ers w^iat they wanted: no cables at all. The f)nly disadvan- 
tage was that this infrared connection was output -only. 



Input/Output Needs of the HP 48SX 

Market research indicated that an overwhelming major- 
ity of high-end calculator users either owned or had access 
to a personal computer. Clearly, it would be an advantage 
to be able to perform the data-entry-intensive tasks with 
tlie large keyboard and display of the personal computer 
and the computation- oriented work with the simple and 
powerful applications resident in the calculator. In other 
cases, the portability of the calculator was essential for part 
of the job and the speed and capability of the personal 
computer and its associated peripheral devices satisfied 
the rest of the need. These considerations forced the pri- 
mary objective for the input /output capability of the HP 
48SX scientific expandable calculator: an easy-to-use con- 
nection to existing personal computers. 

In addition, there were two secondary objectives. While 
most users would choose to satisfj^ their needs for hard 
copy with the printer connected to their personal computer, 
there would be some applications ivhere porl aisle printing 
was essentiah and perhaps some users who needed simple 
hard copy without access to a personal computer system. 
Also, our experience with the HP 41 calculators had shown 
that users of this class of machines do a lot of shaiing of 
programs and data. In consequence, it was felt necessary 
that the HP 48SX be compatible with tho existing infrared 
printer and that there be a convenient way to do input/out- 
put directly between calculators. Fig. 1 illustrates the 
desired input/output connections. 

The most common interface on personal computers is 
the RS-232 serial port. It would be much too costly and 
inconvomient to require the customer to buy a special card 
for the personal computer, such as an HP-IL or infrared 
interface, to connect to I he calculator, Development of these 
cards would be costly, too, since there are several different 
types of personal computers. These considerations quickly 
led to the decision to design into the HP 4BSX the capability 
to connect directly to the serial port already in nearly all 
personal computers. This required a custom connector and 
cable, since the traditional DB9 or DB2,5 connectors used 
with RS-232 were much too large. 

The requirement for program and data sharing between 
calculators could also be satisfied with RS-232. but the 
need to have the cable and /or some special calculator-to- 
calculator adaptor was a severe drawback in this situation, 
A one- way infrared interface was already needed to main- 
tain compatibility with the infrared priider. Would some 
enhancement of I his int(?rfac:e fill the neeci without requir- 
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ing the user to carry around a cable? Some investigation 
showed that a simple infrared receiver circuit tor very short 
distances could indeed be included with minimum impact 
on the design. 

The input/ output solution for the HP 48SX is really two 
solutions, each optimized to particular requirements: the 
serial port for the imporiant connection to personal com- 
puters, and a new two-way infrared interface for compati- 
bility with the portable printer and for calculator-to-cal- 
culator communication. The plug- in memory cards, which 
are essential for memory expansion, mighl also be consid- 
ered part of the solution. The RAM cards with built-in 
battery can be used for archiving and backup purposes and 
for program and data sharing between calculators as welL 
This provides only a partial solution, how^ever, and the 
relatively high cost of the cards makes it very desirable to 
provide these functions in other ways also. 

The input/ output capability consists of not only the elec- 
tronics, but the protocol and software to allow the user to 
move data easily. Here again, what w^as w^idely available 
for the personal computer was the important consideration. 
The Kermit protocol^ was chosen because it provides auto- 
matic retransmission to correct errors, is widely used, and 
i^ available essentially free of charge for all the major types 
of personal computers. It was decided to include the Kermit 
protocol as one of the built-in applications in the HP 48SX. 
The Kermit protocol is applied to both the serial interface 
and the infrared interface, so the user only needs to learn 
one simple application for most input/output needs. 

The Serial Interface 

KS-23Z uses bipolar signaling, that is, different logic 
states are indicated bv voltaoes that swing both above and 
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Fig. 1. The HP 48SX calculator 
can communicals with personal 
computers or other RS-232 de- 
vices, with the HP 82240 portable 
infrared printer, and with ar)other 
HP 48SX via a short-range two- 
way ff^lrared link. 



below the ground reference level. Tlie HP 48 SX does not 
otherwise need to generate a negative voltage, and it would 
seriously complicate the system design to have to do so. 
While integrated circuits are available to perform this fimc- 
tion, their cost and power requirements are prohibitive in 
the calculator. One possible solution was to use unipolar 
signaling. While this is not really RS-232, most receiver 
circuits change the indicated logic .state at about one volt 
positive, and will therefore function acceptably with a 
unipolar input. There are a fewf serial interfaces on personal 
computers, however, with input thresholds that really are 
set at zero volts. These would not work reliably w^ith uni- 
polar signals, and worse yet, customers have no easy way 
to tell which type of interface they have, 

The solution to the problem was found in clever use of 
the voltages the HP 46SX generates to drive the LCD dis- 
play. The logic in the calculator W'Orks between zero volts 
and the Vqd supply, about 4.3 volts. The display works 
between zero volts and the Vh supply, about BA volts. 
Because the calculator has no external ground connection 
to any other device, it does not matter what voltage level 
W'e use as the ground reference for the serial port. By using 
the Vdd supply as the signal groimdt w^e can drive the TXD 
(transmit data) line to calculator ground and it w^ill be at 
-4,3 volts as viewed by the receiving device. Likewise ^ 
driving the line to V^ will make it appear as -4.1 volts 
(Vh - Vod) ^t tlie serial port. The result is a bipolar signal 
that will w^ork with all serial ports without the additional 
expense and pow-er of special integrated circuits. 

Technically, an RS-232 device is required to sw-ing at 
least 5*0 volts above and below signal ground. After various 
circuit losses, the HP 48SX voltage swing is only a little 
more than three volts positive and negative under worst- 
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case conditions. It would have been convenient if the power 
supplies w ere at a slightly higher voltage, hut this was not 
possible since the CPU integrated circuit has a maximum 
voltage limit of about nine volts. Even though this does 
not strictlv comply ivitk the requirement it works quite 
w^ell with short cables since an RS-232 receiver is required 
Id indicate a logic i^ero for -^3.0 volts or more and a logic 
one for — 3.0 \ ohs or less. The siightiy reduced noise mar- 
gin has had no noticeable effect* 

It would have been convenient, though slightly more 
costlVf to use a standard driver/receiver integrated circuit 
to pro\dde the necessan' short-circuit protection and com- 
ply with other interface requirements. Unfortunately, these 
parts are not specified at the low voltages used by the HP 
48SX and their higher voltage drop would have caused the 
output to be less than what was needed. Strict limitations 
on the amount of current that the two power supplies in 
Ihe HP 48SX can source or sink also mandated a discrete 
circuit to satisfy all the needs. 

Considerable experimentation resulted in the circuit of 
Fig. 2. When the TX line from the CPU is driven high fV^[), 
current flows through R2, Q8. and CR5 to the TXD pin and 
the load in the receiver of the other serial device. If this 
current exceeds about 4 milliamperes, the voltage drop 
across R2 will turn on Q7. This will cause the voltage at 
the base of QB to rise, tending to turn QB oft. Thus the 
current that will flow is limited regai'dless of the voltage 
on the TXD pin. Because the circuit is symmetrical, pre- 
cisely the same action occurs wuth Q2 and Q3 when TX is 
driven low (calculator ground), The Sciiottky diodes, cho- 
sen for their low forw^ard voltage drop, are necessar)- to 
prevent reverse conduction through whichever side of the 
circuit is off. The capacitor on the TXD pin slows the rise 
and fail limes of the signal to minimize electrical noise 
generation. The 12-volt Zener diode on the TX lino provides 
additional protection to the CPU from electrostatic dis- 
charges. Capacitor C4 is needed to provide dc isolation 
between the calculator shield, which is at calculator ground 
potentials and the shield of the other device, which is likely 
connected to signal ground, which is connected to the cal- 
culator Vnn supply. Without this capacitor, the calculator 
Vnjj power supply w^ould be short-circuited. 



Receiving RS-232 signals in the calculator is a relatively 
simple matter. When the RXD [receive data) line swings 
positive, the 2.4V Zener diode allows the voltage to rise 
above the logic threshold of the RX input on the CPU chip 
(about one volt above V^o), but clamps it below the CPU 
Vh power supply so that excessive current cannot flow. A 
similar situation occurs for negative swings as the diode 
conducts in the forward direction. The 5.5-kilohm rt^sistor 
limits cnrrent and presents the proper impedance for an 
RS-232 input. The 1.5-kilohm resistor adds additional 
short-circuit and ESD protection for the CPU RX input. The 
75-ohm resistor merely provides a protective current limit 
between signal ground and the Vqd supply. 

The Infrared Interface 

Transmitting infrared light is relatively simple from the 
viewpoint of the hardware. Fig. 3 shows the schematic 
diagram for the infrared transmitter and receiver circuits. 
Because of the high current pulses needed to drive the 
infrared LED, it is connected directly to the batteries, 
greatly reducing peak demand on the calculator power sup- 
ply. The other end of the LED is driven low by a special 
con St ant -current driver circuit integrated on the CPU chip. 
Pulse duration and timing are controlled by a combination 
of hardware In the CPU and firmware. 

A photo transistor was chosen as the receiving element. 
While much slow^er than a photodiode. it is fast enough 
for the data rate of 2400 bits per second ♦ and the sensitivity 
is much greater, Since high ambient light levels can cause 
relatively large currents to flow in the phototransistor. Q4* 
some means had to be found to reduce or stabilize the bias 
current. It would not he acceptable for battery life to be 
considerably shorter in sunlight than in the office. For this 
reason, the phototransistor chosen is one that has all three 
terminals accessible. The combination of this feature and 
transistor Q5 provides the needed stabilisation. If the quies- 
cent current of Q4 increases, this increase goes into the 
base of Q5, which in turn conducts more current away from 
Q4's base terminal, tending to reduce its quiescent current. 
In the office, the total current resulting from thfi intVarf^id 
ref:eive circuit is only about seven microamperes. In direct 
sunlight, this value rises to nearly 200 microamperes. This 
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Rg, 2, JhB discrete aycuitry for 
the HP 48SX serial port provides 
protection for the calculator and 
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seems like a large change, but without the stabilization 
circuit the sunlight value would be several milliamperes. 
and the circuit would saturate and not function. 

Capacitor C5 is necessary to bypass the stabilization cir- 
cuit at the signal frequency. RIO and Rll form a bias net- 
w'ork and threshold -setting mechanism for Qb, the output 
amplifier iind buit'er, Q6 drives the IRI pin on the CPU, 
which includes a pull-up device. If the circuit were to draw 
current even while the calculator is lurned offs higb 
ambient liglit w^ould result in a significant reduction of 
battery life. For this reason* the infrared receiver is powered 
by Vqq. a gated version of the V^d supply which is switched 
off w^hen the calculator is off 

While this system is limited to a range of only two or 
three inches, il is low in cost and provides the user a very 
convenient means of sharing programs and data. 

The infrared coding for the printer has been discussed 
previously." Coding for the two-way infrared data for cal- 
culaior-to-calculator communication is very similar to cod- 
ing of daia from the serial port. Fust is a start bit (logical 
zero), which triggers the asynchronous receiving circuitry. 
Then follows the least-significant bit of data and so on to 
the most -significant data bit, for a total of eight data bits. 
If parity is enabled, the eighth data hit is replaced by the 
parity bit. The HP 48SX sends slightly more than tw^o stop 
bits (logical one hits), hut only requires one stop bit when 
receiving. Fig. 4 shows the liit coding for both the serial 
link and the tw^o-w^a^^ infrared [ink. A logical zero is rep- 
resented by n single pulse of infrared light about 50 micro- 
seconds long. A logical one bit has no light pulse. When 
these pulses are received, a latch-and -sample circuit in the 
CPU converts this format into logic levels, which can then 
be routed into hardware shared with the serial port. Note 
that two-way infrared data is only sent at 2400 bits per 
second, whereas serial data can be sent at 1200. 2400, 4800, 
or 9000 bits per second. 



Rg, 3. The infrared cifcuiiry frarrs- 
mfts to the portable infrared printer 
and provides two-way communis 
catfon with another HP 48SX. 



The User's Point of View 

As anyone who tias used RS-232 knows, plugging the 
cables together is only the beginning. Even for RS-232 ports 
that dan*t require a response on the hard ^va re handshake 
lines, the transmit data and receive data lines may need to 
be reversed. After getting the cable weiring right, the baud 
rate, parity ^ and softw^are handshaking such as XON/XOFF 
must be set identically for both the transmitter and the 
receiver. 

The HP 48SX design attempts to minimize cabling prob- 
lems by using only the minimum three-wire RS-232 con- 
nection [transmit data, receive data, and signal ground] 
and matching the cable pinout to the most commonly used 
RS-232 ports. A setup menu is included in the first row of 
the I/O menu to allow the user to see and modify the current 
setting for baud rate, parity, and other parameters. Since 
the HP 4BSX uses XON/XOFF handshaking only for low-level 
I/O commands, the XON/XOFF setting isn't included in the 
setup menu. Most of the parameters In the setup menu are 
stored in a variable named lOPAR, w hie li also contains sepa- 
rate XON/XOFF handshaking flags for receive and transmit. 

Character ' e \ Hexadecimal 65, Oecrmal 101 
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Fig. 4. Coding of data in ttse two-way infrared protocof Is 
sirniiaf to that in the seriat tink. A togic zero has a pufse at 
the beginning of the bit time; a logic one bit has no pufse. 
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TliE higher-level I/O cominaiids don't use XOlSLXOFF hand- 
shaking since they follow the Kerrait protocol, which has 
packets of at most 96 bytes. 

The simplest I/O interface for the user is the tvvo-way 
infrared interface, which has no wires to mix up. doesn't 
use XON/XOFF handshaking, and is fixed at 2400 baud and 
DO parity. 

All I/O conmiantis on the HP 48SX automaUcally turn 
on and initialize the appropnate I/O port (RS-232 or 
infrared) based on the data from lOPAfl. Once the port is 
ready* the HP 48SX interrupt system receives b\i:es for 
either RS-232 or two-way infrared I/O, The HP 4aSX can 
respond quickly enough to incoming bytes so that even at 
9600 baud the interrupt system will read the first byte 
before it is overwTitten by the next one. Incoming bytes 
are placed in a 255'byte input buffer. The interrupt system 
waits for about four b>ie times before concluding that the 
incoming b\1e stream has ended. Then, before exiting, it 
checks for other sources of interrupts such as cursor blink, 
clock ticks (if the clock is ticking in the display), alarms, 
cards pulled out or added, or keys down or up. 

All of these checks can make the time required to exit the 
interrupt system and then reenter long enough that incoming 
bytes may be missed. For this reason, alarms, key presses* 
and the clock display should be avoided during I/O* 

Low-Level I/O Commands 

The HP 48 SX provides a triplet of low-level f/O com- 
mands: XWIT [transmit). BUFLEN (buffer length], and SRECV 
(serial receive). They are intended for u.se in programs, so 
instead of stopping the program when an I/O error occurs, 
they simply return a succeed/fail flag to level 1 of the stack. 
This allows the programmer the option of handling the 
error without havij^g to use IFERR XMIT transmits a string 
from the stack, usin^ XON/XOFF handshaking if transmit 
pacing is enabled. BUFLEN teJLs how many bytes are in the 
input buffer, SRECV reads a specified number of bytes from 
tlie input buffer [waiting for more to come in if necessary) 
and returns them as a string to the stack. 

Supporting commands are STIME [serial timeout), SBRK 
(serial break}. OPENIO (open 1/0 port), and CLOSEIO (close 
I/O port). STIME sets thR length of time that XMIT (XOFF 
received, transmit pacing enabled) or SRECV uiil wait 
before giving up H the data flow is intcrruptod. SBRK sends 
a serial break. OPENIO and CLOSEIO turn the 1/0 port on 
and off. 

As pointed out earlier, bytes can be lost during I/O trans- 
missions. If the I/O connection is noisy, bytes can be gar- 
hied. It is also possible that some communication channels 
will remove certain bytes (usually control characters) from 
the data stream. The low -level I/O commands have no pro- 
tection from this type of data corruption except for parity 
checking. The Kermit ju'otrjcol chosen for higher- level I/O 
commands overcomes these problems to give more reliable 
communication for transferring programs and data. 

The Kermit Protocol 

The Kermit protocol encodes control nharacters as 
sequences of ordinary printable characters so they can pass 
.safely through to the destination. Garbled data is detected 
by the t:hecksunis on each packet and lost packets are 



detected by the sequence number on each packet. A Kermit 
protocol packet consists of a mark byte to mark the start 
of a packet, a length byte, a sequence number byte, a type 
b\'te, data b\ies, and finally one to three checksum b^ies. 
The type byte defines the type of the packet 

A typical Kermit protocol transmitter sends the following 
packet sequence. After sending each packet it waits for the 
receiver to send either an ACK packet (ty-pe Y) to indicate 
successful receipt of the packet or a NAK packet (type N) 
to indicate a garbled packet. If the receiver doesn't respond, 
the transmitter can time out and resend. 

Sequence Packet 
Number Type Description 



t) 



2 


D 




D 




D 


n 


D 


n-hi 


Z 



n + 2 



S Negotiates parameters such as 

maximum packet length, time-out. 

and control character encoding. 
F Contains the name of the file 

to be sent. 

Data (as many packets as necessary). 



Marks the end of this file. Maybe 

followed by another F,D D,Z 

sequence or by B. 
B Mar ks the en d of the wh ole transfer. 



The packet sequence numbers wrap back to after packet 
63. If either the transmitter or the receiver encounters a 
fatal error, it can send an error (type E) packet to tell the 
other unit to give up also* 

The Kermit protocol has another mode setting in addition 
to parity and baud rate: text versus binary. Computers send- 
ing text files are required to end each line of text with a 
carriage return characte^r followed by a linefeed character. 
If a computer normally uses some other line terminator, 
such as a i^ingle linefeed, it must transform linefeed to 
carriage return plus linefeed when sending text files, and 
must translate carriage return plus linefeed to linefeed 
when receiving text fUes. If a computer normally terminates 
text lines with carriage return plus linefeed, no transforma- 
tions are needed. This works fine for text files but not for 
binary files like compiled programs unless the transmitter 
and receiver both do the transformations or both don't do 
them. Therefore, to send a binary file, a computer that has 
text ^nd binary modes must be set to binar}'. 

The HF 4aSX greatly extends this concept of text (ASCII) 
versus binary files by automatically converting an object 
to string form when sending in ASCII mode, thus convert- 
ing a binary object into its text form. In addition, the HP 
4BSX has a 256-character character set based on the ISO 
8859 Latin 1 character set. This is not compatible with 
many current PC character sets, so translation modes were 
added to ASCII tran.smission to convert the new character 
codes to sequences of normal ASCII characters. To ensure 
the accurate interpretation of the automatically generated 
text form of objects, a header string is prepended to the 
object. This string contains the modes in effect when the 
text form of the object was created. The modes are the 
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translate mode {to allow proper "untransJation"). angle 
mode (in case the object contains a complex number in 
polar form), and fraction mark (to distinguish decimal 
points and argument separators)* The header string aJso 
allows a receiving HP 4fiSX to know that it should receive 
this object in ASCII mode. A short header Is also prepended 
to binary objects to instruct a receiving HP 4BSX to receive 
in binary mode. At the cost of this small amount of extra 
overiiead, a receiving HP 48SX can correctly interpret an 
incoming file even if its modes are set differently than 
w^ould be required for that file. 
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Manufacturing the HP 48SX Calculator 

Sharing manufacturing processes with earlier, simpler 
calculators shortened development time and improves 
manufacturing efficiency. Tfie HP 48SX and the simpler 
calculators also share the same production line at the same 
time— a concept known as coproduction, 

by Richard W. Riper 



THE HEWLETT-PACKARD 4SSX is an advanced sci- 
entific calculator that reaches new levels of capabil- 
ity and performance. Rather than start with a clean 
sheet, the dei^ign team looked to simplify HP's calculator 
line when developing the HP48SX Jn parlicnlarby making 
use of common manufacturing processes. This reduced the 
time to develop the calculator. Sharing common assembly 
techniques with other HP calculators has also led to 
improved produfition efficiency and increased llexibtlity. 

Common Processes 

When work started on Hie HP 48SX* design engineers 
were given the goal to use as many of the design concepts 
from a l-and-2-line display family of cah;ulatora [HP 10, 
14, 17, 20, 21, 22» 27t 32, and 42] as possible. This was 
done to reduce the amount of new development needed 
and to allow the new machine to be built on the same 
production line as its simpler cousins. The l-and-2-line 
family set new standards in HP for calculator manufactur- 
ing efficiency and we wanted to extend this efficiency to 
the HP 48SX. Using proven designs shortened the typical 
design/build/test/redesign cycle, shortening the whole 
design process. It also meant thai there were no new man- 
nfacturing processes to develop. This reduced the cost and 
delivery time for the assembly tooling. Since these tools 
w^ere for familiar tasks, experience gained from the first set 
of tools led to better, more refined tools for the HP 48SX, 



Mixed Production 

The major difference between the l-and-2-line family of 
calculators and the HP 48SX is in the complexity of the 
electronics. Most of the assembly steps needed to build the 
HP 48SX happen as quickly as they do for the simpler 
calculators. How^ever, the HP 48SX's complexity requires 
inspection and test times three to four times those of the 
simpler machines. Since the HP 48SX Is designed to be 
built on the same production line as the simpler model s, 
this could have led to some major line balancing problems. 

One solution to this problem would be to duplicate the 
inspection and test stations so that the whole line could 
run at the same high rate as it does for the simpler cal- 
culators. This would cost a great deal for duplicate test 
equipment. Also, more people would be required when 
building the HP 48 SX, who would not be needed when 
the simpler product was being produced, 

Another solution would be to run the whole line at a 
sknver rate to match the longer test and inspection times. 
This would lead to lower efficiency, since many of the 
faster operations would sit idle through part of the longer 
cycle time. 

To solve 1±Lis problem, we decided to build both the HP 
48SX and the simpler calculators at the same time using 
a process we call coproduction. One of the l*or-2-hne cal- 
culator models is built at the same time and on the same 
assembly line as the HP 4BSX. The products are mLxed 
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uniformly. In the desired quantity ratio. The assembly steps 
shared b}' both machines nm at the higher rate of the orig- 
ina! t-or-2-line assembly line. Since the test and inspection 
stations are peculiar to each product, the more complex 
HP 48SX c^n spend the longer time needed for testing, 
while sevefal of the simpler products get tested at the same 
time. 

The overail result is a line that builds almost as many 
combined ujiits as the simpler line did by iisaU. It can run 
this mix cons tan tlVr rather than building one model of cal- 
culator for a time and then switching to the other. This 
eliminates large changes in the number of people required 
on the line and leads to better use of expensive equipment. 
The mix ratio is not feed, so changes in the number of 
each product produced can be made to suit changes in 
orders. 

Conveyor Production 

The production of the HP 48SX is divided into two main 
areas: printed circuit assembly * where the circuit board is 
loaded, soldered, and tested, and final assembly » where 
the loaded circuit board is brought together with the case 
parts, displav. and keyboard. In both areas a pallet conv^eyor 
is used to move the unit from station to station. The pallets 
are rectangular steel plates surrounded by plastic frames 
tFig. 1 ), The plates have details to hold the parts in position. 
The pallets ride on plastic belts, which never stop mov- 
ing. Al each station a stop mechanism halts the pallet while 
the flat belts continue to slide by underneath. At stations 
where accurate part location is required, the pallet is lifted 
off the belts and registered by the precision bushings that 
hold the pallet together- 
Each conveyor system is made up of tw^o sections ot bell 
side by side. The assembly steps are done on the side 
nearest the operator, while the conveyor on the back side 
is used to move empty pallets back to the head of the line. 
The pallets follow this flat, rectangular loop and never 
need to be removed from the conveyor. 




Fig. t, Assembfm^ are carried on pa//efs !hat ride on con- 
veyor belts. The line nas seven robot stafions. 



Printed Circuit Assembly 

Printed circuit assembly starts with an operator appMng 
solder paste to the bare cixcuil board. This paste is made 
up of small balls of solder held in a solvent base. A printer 
pushes the paste out though a stencil (0,0D4-inch-thick 
brass) onto the pads for the component leads. The operator 
then loads the board onto an empt\^ pallet on the conveyor 
(Fig, 2}. All of the pallets on this conveyor are the same, 
and can hold the HP 48SX boards as well as those for the 
simpler products. The pallet then moves into the first of 
seven robot stations. Each station has a sensor to determine 
if the board on the pallet is an HP 48 SX board or a board 
for a l-!ine or Z-line calculator, so that the robot will load 
the correct parts. 

The first robot loads the ILTS CPU (central prijcessing 
unit) onto the HP 48SX board. Instead of using the tradi- 
tional integrated circuit package consisting of a plastic body 
with leads, the CPU is packaged on a continuous tape (Fig, 
3), This is known as TAB (tape automated bonding). Not 
only is this package styie thinner than plastic bodies, but 
part handling is reduced. The ICs are simply rolled up on 
this reel of tape like 3 5 -mm movie film. This tape is fed 
through a machine that shears the leads out from the tape 
and reforms the lead ends to the optimum shape for solder- 
ing. The robot first uses a reflective optical sensor in its 
gripper to locate the gold-plated traces and solder pads 
accurately on the printed circuit board, ft then picks up 
the IC from the feeder and places it on the board, correcting 
its position based on the optical search. 

At the second robot, connectors for the plug-in cards and 
input/output port are loaded. Also loaded is a TAB clamp ♦ 
which will hold the leads on the TAB IC down while the 
solder paste is reflowed. ensuring a high-quality solder 
joint. After this robot the hoard moves into a heated press 
that forms rivet-type heads on plastic bosses, which will 
hold the connectors and the TAB clamp tightly to the board. 
At the third robot, the random-access memory (RAM) is 
loaded, along with a small coil spring that will make contact 
with a piezoelectric beeper. This spring eliminates the need 
for hand-soldered wires to the beeper. The fourth robot 
doesn't load any parts on the HP 48SX board, but is used 
on some of the simpler products. 

At this point the simpler boards ore completely loaded. 
The pallets carrying these boards are moved to the back 
belt, where they travel up to the second robot's area. There 
the second robot takes the board off the pallet and places 
it on a simple flat belt conveyor to move it to the solder 
reflow machine. 

The pallets holding boards for the HP 48SX continue 
down to robots 5,6, and 7. where the rest of the components 
are loaded. Since only a fraction of the total pallets continue 
oUt the cycle time at these last three robots can be longer. 
This is a good example of where the coproduction scheme 
pays off. These robots can load many more parts than if 
I hey were limited to the shorter cycle time of the first four 
roljots. After the final robot, the pallets move to the back 
belt, where they travel up to the second robot. As in the 
simpler product, the HP 48SX boards are off-loaded to sol- 
der reflow. The empty pallets continue to the head of the 
conveyor line, ready to repeal the process. 

After loadingt the boards pass down a conveyor belt to 
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Fig. 2. HP 4fiSX Qrmte^ circuit 
assembly production line layout. 



an infrared reOovv machine. The boards are then inspected 
under a microscope for solder joint quality and component 
alignment. Next the TAB clamps are removed, because 
there isn't room for them in the final product. A few com- 
ponents that are not surface mounted are added to the 
board by hand, and then the hoards are washed to remove 
solder flux and other contaminants. The boards are next 
tested on an HP 3065 boaid test sysleni. then passed on to 
final assembly. 

Final Assembly 

The final assembly line is similar to the conveyor used 
for printed circuM assembly, but the pallets are larger. Also, 
different pallets are needed for t he HP 48SX and the simpler 
l-and-Z-line products. Sensors al e;ich station read the pal- 
let type and act accordingly. Instead of being totally auto- 
mated ^ the final assembly line is a mix of manual stations 
with robots and other automated stations (Fig. 4). 

The first station is a robot that loads plastic top and 
bottom cases into the pallet for the simpler calculators. 
This station is not used for the HP 4BSX because the case 
parts are larger and could not he ii^d to the robot in the 
same way. At the next two stations, operators place case 
parts for the HP 48SX into the pallet and load keyboartf 
parts for both products. 

The next station is a pair of robots that work together to 
align and load the liquid crystal disphiy (LCD) into the 
metal chassis and then load the chassis into the topcase, 
which is waiting on the pallet. One robot picks the LCD 
up fi'om its shipping tray and places thin strips of double- 
stick tape along both long edges. It then passes the LCD 
off to the other robot. This second robot locates the LCD's 
contact pads under a reflective sensor and uses this search. 



information to place tlie LCD accurately into the metal 
chassis. Locating details on the chassis accurately carr^^ 
this alignment to the pads on the circuit board. 




Rg. 3. 1LT8 ICs are packaged for tape automated bondmg 
(TAB) and can be handled like movie film. 



The pallet then travels into the first of four heated presses 
used to hold the calculator together; no screws are used. 
Thiee of these four heatstakers work on both product types, 
so the product type is sensed and the top portion of the 
tool automatically shifts the correct heater block into place. 
The fourth heatstakeris only used on the l-and-2-Iine prod- 
ucts, so the \i¥ 4BSX pallets simply pass through. The first 
heatstaker forms rivet-style heads on bosses in the topca.se. 
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holding the chassis and keyboard parts tightly together. 

The pallet now moves into a set of manual stalions where 
the printed circuit assembiies are added. Elastomeric con- 
nectors knowTi as zebra strips (for the aJlemating black 
carbon conductor barsK which make the electrical connec- 
tion betiveen the LCD and the printed circuit assembly, 
are loaded onto the LCD. and tiien the printed t:irr:uit assem- 
biy is added. 

Autofnated Vision and Functional Tests 

The pallet then moves to a series of testers. The testers 
for the l-and-2-Iine family are located on the conveyor, 
and the HP 48SX pallets pass through these without stop- 
ping. The testers for the HP 48SX are located to the side 
of the main conveyor line just past the simpler testers. The 
HP 4BSX pallets are automatically moved off the main line 
into the testers. This allows them to take longer lo test 
without holding up movement of the simpler products, 
which test much more quickly. After testing, the HP 48SX 
pallets are moved back onto the main line to continue to 
the next station. 

In each tester, the pallet is raised up against a test block 
(Fig. 5), Tills block contains spring-loaded probes which 
make electrical contact to test pads on the circuit board. 
Small air-powered cylinders can press on each key on the 
keyboard of the upside-down calculator, both to test the 
keyboard and to start a number of self-tests that are built 
into each calcirlator. Cameras mounted at the bottom of 
the tester look up at the display and an automated vision 
system checks to ensure that the whole display "lights up" 
as the calculator runs through Its self tests. HP histruments 
check current levels and measure the operaling frequency. 

Once the calculator passes these tests, metal tabs formed 
as par! of the chassis are automatically twisted to hold the 
printed circuit assembly, zebra strips, and LCD together. 
If the unit fails the test, a mechanical test failed code is 
set on a code block mounted on the pallet. Following the 
test stations is a mechanism to move failed pallets lo the 
back belt, where they will loop back to the stations where 



the printed circuit assembly was loaded for evaluation. To 
aid rework* an error reporting system using an HP Vectra 
personal computer lets the operator at that station know 
which test the unit failed. 

The pallets then pass through a heatstaker to stake in an 
aluminum electrostatic discharge shield and the piezoelec- 
tric beeper. At the next manual station, additional shielding 
parts are added by an operator and the cases on the HP 
48SX are joined together. The cases are joined on the sim- 
pler products automatically. The calculators then pass 
through a pair of heatstakers to join the cases together per- 
manently. Again* no screws are used. 

Next, an operator places a printed overlay over the 
keyboard, which is pressed on at the next station. At the 
last set of stations, operators load the batteries and doors, 
and perform cosmetic and hmctional tests. The calculators 
are now ready to be packaged with the instruction manual 
in the box for shipment to the dealer. 

Conclusion 

As described above, many of the assembly steps for the 
HP 48SX are shared with similar steps for the simpler 1- 
aiid-2-Une series of calculators. By basing the design of the 
HP 4aSX on this earlier product line, the same production 
line can be used to build both type of products. By using 
the coproduction techniques described above, both prod- 
ucts can be built at the same time, leading to better produc- 
tion efficiency and people balancing. 
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Fig. 5. This tesfer uses two cameras and an automBted vision 
system to inspect tlie catcuiator's; disptay. 
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A 10-Hz-to-1 50-MHz Spectrum Analyzer 
with a Digital IF Section 

The HP 3588 A' s digital resolution bandwidth fitters offer 
better shape faotors and can be swept four times faster than 
their analog counterparts. Narrowband zoom measure- 
ments using fast Fourier transform analysis can be hun- 
dreds of times faster. Extensive self-calibration, a help sys- 
tem with hypertext, and adaptive data acquisition also 
improve performance. 

by Kirsten C. Carfson, James H. Cauthorn, Timothy L. Hillstrom, Roy L. Mason, Joseph F. Tarantino, 
Jay M. Wardfe, and Eric J. Wicklund 



THE HP 358SA SPECTRUM ANALYZER (Fig. 1] is a 
heterodyned, synthesized instrumont witli a Ixack- 
ing source. It is designed tor speutnim and scalar 
network measure merits from 10 Hz to 15U Mhlz. The key 
measurement contribution of the HP 3 5 88 A is fast, high- 
resolution, narrowband measurements. The HP 3 ^88 A is 
a pioneer in a new era in which spectrum analyzers will 
increasingly use digital signal processing technology to 
improve performance and teatures. By combining digital 
filtering and FFT [hsi Fourier transform) analysis with 
traditional swept spectrum analysis techniques, the HP 
3 5 68 A typically provides four times faster swept measure- 



ments and up to hundreds of times faster narrowband mea- 
surements than were previously available in a swept 
analyzer. The HP 3588A accomplishes this while achieving 
superior amplitude accuracy. 

The HP 3 588 A brings digital signal processing technoi- 
ogies to RF spectrum analysis in I wo waySn For improved 
swept measurements, the HP 3 588 A is the first RF spectrum 
analyzer with an all-digital final IF (intermediate fre- 
quency) section. The selectable bandwidth of the IF sec- 
lion's digital filters detennines the resolution bandwidth 
of the measurement. The filters have precise, predictable 
characteristics and performance that would be impractical 




Rg, 1. The HP 3588 A /s a new 

type of spectrum analyzer that 
greatly improves measurBment 
speed in the frequency range of 
10 Hz to 150 MHz. Resolution 
bandwidth /s seiectatle from 7 7 
kHz down to 0.0045 Hz. The new 
narrow tDand zoom mode aiiows 
fast Founer transform analysis of 
spans up to 40 kHz wide anywhere 
tn the frequency range - 
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to achieve using analog technologies. Signal detection for 
swept measure men Is is also done digitally^ FFT signal pro- 
cessing is used for a narrowband zoom mode. For measure- 
ment spans less than 40 kH^. narrowband zoom mode pro- 
vides all the speed and resolution to 150 MHz that previ- 
ously were only available to users of FFT-based analyzers. 

For swept measurements, ihe digital resolution band* 
width filters provide shape factors of less than 4:1 with 
the same iniierent accuracy obtained using more trad itionai 
IF filters with typicaJ shape factors of 11:K Since these 
filters are implemented digitally, their response is com- 
pletely predictable and repeatable. and tliey can be swept 
faster than the traditional rate of one half the square of the 
resolution bandwidth. Any effects of the filters on the 
response are known and are calibrated out of the measure- 
ment. The result is a sw^ept measurement that is typically 
four times faster and has better than two times narrower 
shape factor than analyzers with analog resolution 
bandwidth filters. It is Important to note that these speed 
improvements are achieved together with the improved 
shape factors. If speed comparisons are made for equivalent 
60-dB bandwidths, even more dramatic improvements are 
seen. Speed improvements under these conditions can be 
in excess of IG times for swept measurements and 1000 
times for narrowband zoom measurements. 

FFT analysis for fast narrowband zoom measurements 
is available at any center frequency from 10 Hz to 150 MHz. 
Signals from the last analog IF section are digitized and 
subsequently filtered. Frequency spans from 40 kHz dow-n 
to T2 Hz are available in this mode, and signals can he 
resolved with 4.5-mHz resolution at frequencies to 150 
MHz- An ovenizod reference oscillator is available to pro- 
vide the frequency stabllily necejisary to make these nar- 
rowband measurements. 

All instrument functions are available over the HP- 10 
[IEEE 4Bf3.2. lEXl t)25), and the instrument can act as an 
HP-IB system controller as well. Optional HP Instrument 
BASIC is available for programming and automated testing. 
A S^S-inch disk drive is an option for storage of inslrument 
states, data, and Instrument BASIC programs. 

Principal applications for the HP 3586A Include general 
spectrum and scalar network analysis to characterize cir- 
cuits and systems in laboratory and automated product inn 
environments. Examples of applications thai benefit from 
some of the new features of this instrument include: 

■ Analysis of nonstatiomiry or short-duration signals such 
as vibration-induced sidebands on oscillators 

■ Radio surveillance and measurements of moving side- 
bands on modulated carriers 

■ Circuit adjustments where fast feedback of results saves 
time 

■ Automated testing using the instrument's internal Instru- 
ment BASIC programming to control repetitive tasks 
(system controller capability over the HP-IB allows sys- 
tem integration without the need of a separate controller 
in ATE applications) 

■ Phase noise and broadband noise measurements (be- 
cause of the detection scheme used^ a true rms level is 
given without correction factors J. 



Development Challenges 

1 hroughout tlie development of this product, many tech- 
nical obstacles were overcome in integrating the digital IF 
and FFT technologies into the instrument: 

■ Custom gate arrays were developed for the digital filters. 

■ Because the instrumeiit measures to 10 Hz. a speciai 
mixer design and a local oscillator (LOl feedthrough can- 
cellation circuit were developed to reduce local oscil- 
lator signal levels in the IF path at low frequencies. 

■ To achieve good amplitude accuracy in FFT-based mea- 
surements. a special technique was developed to cali- 
brate out analog IF frequency response effects. 

■ Residual spurious signals wlth^in the IF passband that 
would never have been resolved in a swepi-only analyzer 
were initially seen using an FFT, requiring special atten- 
tion in development to the reduction of spurious and 
residual signals. 

■ An autoranging input that operates over the full 1 50-MHz 
frequency range is provided. 

■ A multiple-loop local oscillator that includes a frac- 
tional-N loop as an interpolation oscillator was designed 
to provide the synthesizer performance needed for nar- 
rowband measurements.' 

To speed development, the HP 3^66 A incorporates several 
assemblies that were previously used by a low- frequency 
dynamic signal analyzer. Among these assemblies are the 
main processor board [including the disk drive), an aux- 
iliary niemorv board, the front pan eh the chassis. I he power 
supply, and the display. It was quite a challenge adapting 
many of these parts to meet the needs of a high-frequency 
analyzer. An instrument'Specific card nest was added to 
house the HP 35B8A circuitry and provide shielding. Many 
chassis improvements were required to allow tlie HP 3588A 
to meet regidatary RFI requirements and to provide adequate 
internal electromagnetic compatibility to meet perform- 
ance requirements. It was also necessary to synchronize 
the processor clocks (which Indirectly control the display 
clocks) and the power supply switching frequency to thn 
HP 3 588 A reference to pre\^ent interference in the IF sec- 
tions. 

Receiver Section 

Fig- 2 is a hardware block diagram of the HP 3588 A spec- 
trum analyzer 

The receiver section applies gain, filtering, and several 
frequency conversions to condition the input signal. The 
recei%'er contains circuitry to detect the incoming signal 
level and can choose the optimum input attenuator setting 
automatically. The HP 356ftA also provides a low-distor- 
tion mode of operation in which an additional IQ dB of 
attenuation is applied to reduce any distortion products 
contributed by the instrument. Scaling* reference level 
trackings and calibration are unchanged by this mode of 
operation. At the end of the receiver chain are the cuialog-to- 
digital converter (ADG). resolution bandwidth filter, detec- 
tor, and video Olter. All of these filtering and detection 
operations are Implemented digitally in the HP 3588A and 
will be discussed in more detail later. 

Since the HP 35aaA is designed to be used at both RF 
and baseband, the Input impedance is selectable— f50 ohms 
or one megohm. Power is provided for a high -imped a nee 
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Fig. 2, HP 358&A spectrum anatyzer hardware bfock diagram. 



active probe. In the 50-ohm config lira Hon. the signal lave) 
is monitored by an overload detector. In the event of an 
overload, the detector sets the input to the one-meoolun 
impediince setting. This prevents any damage to the 50- 
ohm measurement path* In this situation a message is 
placed on the instrument's display informing the operator 
af the overlnad condition and telling how to reconnect the 
input. In the SO-nhm me^^surement path, a step attenuator 
provides 50 dB of attenuation in 10-dB steps so the signal 
level can be set to obtain the best dynamic range » The 
minimiim and maxlnuim input range settings are — 20 dBin 
and -h20 dBrii. The HP 3588A also has the ability to pick 
the best input range setting automatically. A high-input- 
impedance buffer amplifier in the one-megohm measure- 
ment path conditions the signal and provides a 50-ohm 
output impedance to drive subsequent circuitr}^ 

Following the step attenuator is an amplifier stage with 
a 50-ohm input impedance. This input amplifier is imple- 
mented largely with surface mount components and is 



shielded to prevent interference from externally generated 
signals. The amplifier provides 5 dB of gain, isolates the 
input From ihe rest of the instrument, and to a large extent 
determines many of the instrument specifications [such as 
distortion and noise). The isolation prevents the input 
return loss of the instrument from being affected by the 
input low-pa.ss filter or the first mixer. It also prevents the 
first local oscillator signal from appearing at the instrument 
input. The amplifier also provides a separate signal to drive 
the autorange circuitry. 

The autorange detection circuit is composed of a wide- 
band amplifier, a peak detector, and a main processor inter- 
face. The ampiifier must respond to signals from 10 Hz to 
greater than 150 MHz if the optimum input range is to be 
chosen. The peak detector is designed for minimum tem- 
perature drift. The detected signal undergoes amplification 
and drives two comparators, which can interrupt the main 
processor if an out-of-range signal is detected. Since the 
signal levels are 10 dB lower when the instriunent is con- 

fconlinijeci on page 49] 
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Spectrum Analyzer Self-Calibration 



The HP 35S8A contains extensive seJf-calibraiion capabiiitv 
that allows ft to achieve very good amplklude accuracy and LO 
feedihrough speciricationscompamd lo those previously achiev- 
able On powet-up and penodical^y thereafter, the HP 358SA 
performs seif-caltbrations of the frequency tiatness for all input 
i^anges. the IF fevel and shape. LO teedthrough. and tfie source 
ampSttude. 

Internal Hardware Calibrator 

The internal hardware calibrator provides a preoision 
amplHude reference level of - 20 dBm ± 0.02 dB from 200 kHz 

to 150 MHz. TTiJs signal can be switched internally lo the receiver 
inpat for automatfC range flatness and [F tevel calibration. Fig 1 

shows the calibrator block diagram. 

The limiter conditions the input signal and desensitizes the 
Output level to input level, allowing up to 20 dB of variation at 
the input wsth negligible ouipui variation The dc servo around 
the differential switcher provides precise control of the sum of 
the collector currents, which indirectly controls the average (dc 
value) of the individual collector currents. If the input to the 
switcher is reasonably symmetrical {ue., low even -order harmonic 
contanO, then the fundamentat of the switcher is exaclly related 
to the dc value by 

fundamental rms amplitude = (dc amplitude) \"8'/77 

Thus the servo loop can, in theory, exactly control the level of 
the fundamental of the oulput. PracticaHy, second-order effects 
such as finite switching times and base-to-colleclor feedfon^'ard 
e>5fst. However these effects can be well-controiled with a simple 
frequency compensation network. The impact of employing this 
calibrator in the HP 35eeA ts reflected in the typical absolute 
amplitude accuracy specification of 0,2 dB from 30 kHz to 
150 MHz, 



CalKbratcir Input 
0,2 to 150 MHz 
^5 to -2S dBm 




First LO Feedthrough Nulling 

Jl :s impcnan: lo rn^r^miie LO feecthrough to nrtinimffie low- 
frequency residuals and lo reduce the problem of muftipte tones 
m me IF at lov. '^ ■ -^s The HP 3588A incorjxsrates a circuit 
to reduce the jn level to at l^si 20 dB below range 

under ail con d si. ens 

LQ feedthrough nulling is accomplished by a cifourt which 
feeds a small amount of the mam (swept) LO ssgnal around the 
first mixer The in-phase and quadrature components of thts sig- 
nal are adjusted by the ins^rumient's mam processor while 
monitoring the response when tuned to zero Hz A very simple 
gradient search algorithm is used to find the mintmum feed- 
through level The tuning ]S done by means of two "electronic 
potentiometers' which adjust the resistive and reactive imped- 
ance components of the feedforward circuit. The resistive com- 
ponent is adjusted by varying the current through a pin diode. 
whrle the reactive component is adjusted by a half-bridge com- 
posed of two WC (voltage variable capacitor) diodes (see Fig. 2), 

IF Filter Shape Calibration 

The overall cascaded IF shape must be measured so that the 
contribution of the IF response away from its center frequency 
does not degrade the performance for narrowband zoom mea- 
surements. This is accomplished by sweeping past an internal 
fished -frequency signal so that the IF! requency response is traced 
ou! in reverse. This response is then reversed and interpolated 
as needed to correct any subsequent narrowband zoom mea- 
surements. 

Source Calibration 

The HP 3588A source oulpul amplitude is calibrated using the 
previousty calibrated receiver. The output amplitude is measured 
during self -calibration at two amplitude settings using a direct 
internal path between the source output and receiver input. From 
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Fig, 1, HP 3588 A Oaiibrator, 
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ihese measurements, constants are caSculated that correct for 
gain errors in the source IF and amplilude control circuitry and 
for offset errors in the amplitude control circuitry. A manual 
amplitude adjustment is not required. 
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Figured in its lovv-distortion mode, the lower autorange 
threshold must also be reduced by 10 dB in this mode. 
Detection of an underrange condition at this level is dif- 
ficult, so the autorange algorithm is defeated in this case. 
However, a single autorange can still be performed, bUow- 
ing a one-time optimization of the signal leveL 

The main signal path intrudes a 150-MHz low -pass filter 
between the inpiit amplifier and the first conversion to 
prevent oul-of-band signals from appearing at the mixer 
input. This filter is a ninth-order Chebyshev design with 
an integral amplitude equalizer* The filter is implemented 
w4th printed circuit inductors and surface Ttiount capaci- 
tors and consistently demonstrates passband frequency 
response flatness of 0.4 dB. Special care was taken to shield 
this filter so that sect ion-to-sec I ion crosstalk does not com- 
promise stopband performance. Because this filter is also 
used in the source section of the instrument, development 
time was reduced. We were also able to reduce manufactur- 
ing cost since all of the parts are placed by machine, and 
we were able to reduce the time for final test since no 
adjustments arc required. 

The first conversion follows the low-pass filter and trans- 
lates the input signal to a fixed first Intermediate frequency 
of 310.1875 MHz. The first local oscillator is synthesls^ed 
and covers a frequency range from 310.1875 MH2 to 
460.1875 MHz. The first LO will be discussed in detail 
later. As in any receiver that must accept a broadband 
input, spurious products, harmonic and intermodulation 
distortion products^and frequency flatness all require care- 
ful attention. It is primarily the first mixer that sets the 
harmonic distortion and residual spurious performance for 
the instrument. Since the design criteria to satisfy these 



goals were in conflict to some extent, achieving the desired 
first mixer performance represented a significant design 
eflbrt. To achieve good distortion performance it is neces- 
sary to operate the mixer at high LO drive levels while 
maintaining symmetry of the drive waveform. Howeverp 
any mixer has finite isolation between its ports^ so higher 
LO levels result in laige amounts of LO signal at the output 
of the mixer. If these signals are not prevented from reach- 
ing subsequent conversions they can produce residual 
[false) responses. Careful filtering and shielding were 
required to minimize these residual responses. In addition, 
a small amount of the first LO signal is fed around the first 
mixer to cancel the mixer's intrinsic feed thro ugh (see 
"Spectrum Analyzer Self-Calibrafinn/' page 47). 

The 310.1B75-iMHz fu'st IF signal is hliered by a four- 
seciion coupled helical-resonator bandpass filter having a 
bandwidth of approximately 3 MHz. Performance and ease 
of manufacture were important in the development of this 
filter. The helix assemblies within the filter are wound on 
supporting cores molded of a very low^-loss fluoroplastic 
to minimize the reduction in resonator Q caused by dissi- 
pation loss. The resonators are aperture-coupled and the 
input and output connections are tapped directlv onto the 
helLx assemblies. Tuning screws with self-locking pellets 
make tuning of the filter easier than if lock nuts were used. 
The heiicaJ-resonator filter mounts directly into a cutout 
at the edge of a printed circuit board and the whole assem- 
bly slides into a card slot as a unit. 

The second conversion translates the signal from 
310,1875 MHz to 10.1875 MHz. The local oscillator for this 
conversion (the second LO). is a phase -locked 3 00 -MHz 
signal also used as an offset in the main (swept) LO. A 
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seven-section LC filter and several gain stages make up the 
second IF section. To achieve the required instntment am- 
plitude accuracy, the behavior of all of the IF amplifiers over 
temperature needed careful attention. Since operating fre- 
quencies and amplitudes are dif Cereal for each EF section, 
various approaches were involved, but each amplifier stage 
received Lodividua! attention. 

The third conversion is accomplished with an active 
mixer, providing gain as well as frequency translation. The 
third LO is a 10-MHz signal phase-locked to the instru- 
ment's common reference. This conversion translates the 
signal to 187,5 kHz, Following the conversion, the signal 
is further amplified and filtered, yielding a final IF 
bandwidth of approximately 40 kHz, .'\n attenuator [set- 
table in 1-dB steps under main processor control) is set so 
the signal is applied to the analog-ta-drgilal converter at 
the optimum level. Conflicting performance goals made 
the design of the third IF challenging. To prevent degrada- 
tion of swept measurement data, the transient response of 
the filter must be well-behaved. However, for good narrow- 
band zoom performance, i:he frequency response of the 
filter should be reasonably flat over the entire 40- kHz IF 
bandwidth, and a filter designed for flat amplitude response 
often has poor transient response. The fiiter circuit was 
simulated and refined until good transient response at Mgh 
sweep rates was achieved, and the flatness variation was 
kept to a level that can easily he calibrated out. 

The analog-to-digltal converter section consists of a 
track-and-hold circuit operating at 250 kflz followed by a 
two -pass converter. This entire section was leveraged from 
a previous product/ The final resolution bandwidth fdter- 
ing, detection, and video filtering are all accomplished digi- 
tally in the HP 3 588 A by two custom gate arrays. 

Digital IF Section 

Gjie of the goals for the HP 3 588 A ^iroject was to reuse 
existing modules wherever prncticirl to minimize develop- 
ment costs. Hewlett-Packard dynamic signal analyzers use 
a chip set of gatearrays that perform many signal processing 
steps: triggering, optional quadrature detection from an 
arbitrary center frequency, programmable information 
band width reduction by decimation filtering, and accumu- 
Itition of complete sample records for later block process- 
ing. The HP 3 5 88 A digital IF section needed to be compat- 
ible with the same analog-to-digitai converter as this chip 
set and at similar sample rates. It also needed to provide 
programmable information bandwidth reduction dnd be 
fairly inexpensive to build. Modification of the dyiianiic 
signal analyzer signal processing chip set seemed to he a 
good approach for the HP 3588A digital IF section, since 
a rapid development cycle was desired. 

This approach to development paid off quite well. The 
digital IF section of the HP 3588 A consists of two gate 
arrays (the filter and the detector), and three RAM chips. 
The dynamic signal analyiter chip set consists of five gate 
arrays and five RAM chips. The decrease in parts count 
was achieved by removing unnecessary functionality and 
by integrating more functions. 

Many modifications were made because of the different 
needs of a swept » high-frequency analyzer and the block- 
record -oriented dynamic signal analyzer, The most im- 



portant difference is that the swept analyzer applies signals 
with constantly changing frequency to the resoiutlon filter. 
The resolution filter must read Id these transient signals 
properlv » The usual implementation for resolution filters 
is an n-pole synchronously tuned filter, which is often 
modeled as a Gaussian fi-et^yency response. The main re- 
quirements are a smooth step response with no ringing or 
overshoot, and good symmetry between the rising and fall- 
ing edges of the response to a swept transient input. 

The filler in the dynamic signal analyzer chip set imple- 
ments a recursively applied decimation algorithm to reduce 
the information bandwidth to the user*s desired span. Each 
application of the algorithm acts as a filter that halves the 
signal bandwidth and a resanipler that then halves the 
sample rate. The decimation filter removes any out-of-hand 
signals that would otherwise alias into the final information 
bandwidth because of under sampling. The fi-equency 
response of this filter has steep skirts and a flat passband. 
which is well-suited to sample rate decimation. Unfortu- 
nately, it has very poor transienl response. The filter gate 
arrav for the HP 3588A uses the decimation architecture 
of the previous gate array, but internally cascades the out- 
put of the last decimation with a filter of appropriate trans- 
fer fimt:tion and transient response for a swept anah zer. 

This new filter is implemented as a finite impulse 
response [FIR] filter. It has a frequency response that is 
roughly Gaussian. Not only does it react much like tradi- 
tional filters used in swept analyzers, but it also provides 
some additional benefits. It is digital and therefore has no 
analog adjustments. Environmental changes do not affect 
its response. It also has a mtich smaller shape factor than 
IF filters in most traditional swept analyzers. It has a 60-dB 
shape factor of less than 4:1 . This means that the frequency 
response cur\^e Is less than four times as wide at t50-dB 
attenuation as it Is at 3-dB attenuation. Traditional resolu- 
tion filters typicEilly specif\^ a 60^dB shape factor ranging 
from 11:1 to 15:1. The aO-dB shape factor in the HP 358BA 
is less than 5:1! This narrower shape factor means that 
larger than normal resolution band widths can be used 
while resolving small signals that are very near large ones, 
thus improving measurement speed. Another characteristic 
of this FIR fiiter is its very predictable reaction to signals 
swept a! faster thai:i normal rates. This makes it possible 
to apply overs weep corrections, thereby providing four 
times faster sweep rates than traditional swept analyzers 
for a given resolution bandwidth without loss of accm-acy. 
The concept of oversweep corrections is discussed later in 
this article. 

The digital input to the signal processing chip set from 
the analog-to-digltal converter is applied to two mixers 
simultaneously. The local oscillators for the two mixers 
are both at the same frequency, but are 90 degrees apart in 
phase. This provides two data streams, one representing 
the real part of the IF signal and the other representing the 
imaginary pari. This quadrature detection is nearly identi- 
cal to that done in the HP 3577A Network Analyzer.'' 

Sw^ept spectrum analyzers detect the scalar magnitude 
of the input signals as they are swept through the analyzer^s 
lb\ The detector gate array converts the real and imaginary 
components of the signal into the magnitude of the signal. 
This magnitude is passed tn Jlu* main processor for sub- 



JUNE 1991 HEWLETT PACKARD JOURNAL 49 



)Copr. 1949-1998 Hewlett-Packard Co. 



sequent processing and display. The complex signal sam- 
ples can also be passed into the main processor for use In 
a fast Fourier transform process whose output can then be 
converted into magnitude and phase. 

The detector computes the magnitude by squaring the 
real and imaginan^ components and then adding them 
together. This results in the square magnitude of the filtered 
signal, which is proportional to the square of the input 
voltage or to the input [jower. 

Since the resolution filter bandwidth may be much nar- 
rower than a bin (display point) on the instrument, a peak 
detection function is also required. This is a standard swept 
spectrum analy^iser function. li the punk detec;tnr were not 
included and the response were just sanipied, a response 
narrower in h'equency than the equivalent frequency spac- 
ing of adjacent pixels on the display could be missed 
entirely. For this reason, ail swept spectrum analyzers have 
a peak detector. The peak detector gets reset whenever its 
output is sent to the main processor and thus to the display. 
Each magnitude sample received by tht3 peak detector is 
compared to the peak detector's current value, [f the new 
magnitude is larger than the current value then the peak 
detector value is updated to the new value; otherwise, the 
current value is retained. 

Swept analyzer users expect to see the screen updated 
as the instrument sweeps, so acquisition of a complete 
sample record is inappropriate. This means that no ret:ord 
needs to be acquired, and detected data needs to be im- 
mediately available to the main processor. The detected 
result is passed to the main processor by an on-chip DMA 
interface- This saves several ICs over tlie previous approach, 
which used a FIFO buffer to acquire a complete sample 
record. 

Traditional swept spectrum analyzers must have a video 
filter. This filter is typically placed after a full -wave detec- 
tor and removes the component at twice the intermediate 
frequency resulting fruin the fiiij-wave detection. The 
detector in the HP 3 5 88 A can be called a power detector 
since it merely takes the sum of the squares of the real and 
imaginary components. This detection technique has no 
resultant component at twice the intermediate frequency, 
so no video filter is needed for most measurements. How- 
evert a video filter is provided for occasions where noise 
smoothing is desired. 

Filtering I he video in the power domain has an advantage 
over the traditional approach. The traditional analog spec- 
trum analyzer IF path has a logarithmic amplifier before 
the full-wave detector. This combination is calibrated for 
sinusoidal signals. However, those detectors respond differ- 
ently to modulated signals and to noasinusoidal signals 
such as noise. For instance, traditional detectors under- 
represent the thermal noise power by 2.5 dB. The video 
filter in the HP :i5BBA does mean square filtering on tlie 
detected signaL It responds to the average power being 
measured and requires no corrections for different kinds 
of signals. 

The detector gate array converts its input to a floating- 
point representation to avoid losing precision. The square 
of the 24-bit input would have to he 48 hits long if kept in 
a fixed'point representation. With the input normalized to 
a floating-point representation, the square of the 24-bit 



mantis,sa can be represented quite adequately with a 24 -bit 
result. The exponent of the square is simply double the 
exponent of the input. The floating-point representation 
chosen is the IEEE single-precision format so that the 
results from this gate array can be used directly by the 
instrument firmwarB. 

Local Oscillator 

The local oscillator (LO) section of the F# 3588A pro^ 
vides a fully synthesized swept signal from 310/1875 MHz 
to 460, 1875 MHz. It can he configured in two waySt depend- 
ing on whether faster sweep speed or better phase noise 
and spurious performance is desired. In the single-loop 
mode I he LO is configiued so that It can sweep the entire 
range of frequencies very quickly. In the multiple-loop 
jnode. a step loop and an interpolation loop are summed 
in a third loop* the sum loop, to produce the desired 
frequency (see Fig. 3). The choice of configuration is based 
on the instrument setup. If the measurement requires a 
large frequency span, single-loop mode is used. Setups 
involving narrower ,spans or resolution bandwidths use the 
multiple-loop mode. All narrowband zoom measurements 
use the multiple-loop mode. Six printed circuit assemblies 
make up the LO section, and many, but not all, are used 
in both modes of operation. The oscillators used for the 
step and sum loops are identicaL and the resultant similar- 
ity of Iheir tuning characteristics aids the overall LO per- 
formance, The oscillators are both volt age- tuned and are a 
negative -re si stance design, with the base inductance real- 
ized by a trace on the printed circuit board. A h^actional-N 
loop is used in both modes of operation to obtain fully syn- 
thesized sweeps and superior frequency resolution (better 
than 0,01 Hz), 

In single-loop operation the sum loop oscillator output 
is divided by 10 to yield a frequency in the range of 
31.01875 MHz to 46.01875 MHz. This signal is the input 
to the fractional -N divider circuit. The output of the divider 
is phase-detected using a lOO-kHz signal from the reference 
section. The loop integrator sums the phase detector output 
current with the API (analog phase interpolation) correc- 
tion currenls, yielding a tuning voltage which is sampled 
and applied to the sum hiop oscillator. 

In multiple-loop operation the step loop output and inter- 
polation loop output are summed to produce the main LO 
output. The step loop provides frequencies from 306 MHz 
to 450 MHz in 2-hlHz or 5-MHz steps* The interpolation 
loop provides continuous coverage of the 2-MHz or 5-MH^ 
bands between the step loop frequencies. The reference 
frequency for the step loop is derived from a 10-MHz signal 
supplied by the reference section. To simplify tlie design 
of the step loop divider and allow for some phase noise 
cancellation, a 300'MHz offset frequency is applied in the 
step loop (see the discussion of the HP 3 588 A reference 
section below). To maintain consistent loop bandwidth 
(and thus phase noise performance) the loop gain of the 
step loop is also adjusted as the divider value is changed. 

The interpolation loop provides fine-resoluiiou frequency 
coverage in multiple-loop mode. It uses the frat:tional-N 
divider, phase detector, and loop integrator/ filter described 
earlier, but tunes a different VCO. The interpolation VCO 
is a single-transistor design tuned with \^^C (voltage vari- 
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able capaeitor) diodes. This design was leveraged Ironi a 
previous product-' To fill in the steps for the two different 
step sizes used by the step loop, the interpolation loop 
VCO is followed by a circuit that divides by either 5 or 10. 

The sum loop combines the step loop and interpolation 
loop frequencies by mixing the step loop frequency wath 
the sum loop frequency and applying the resulting differ- 
ence signal to Ihe sum loop phase detector. The other inpul 
of the phase detector is the interpolation loop signal. The 
resulting sum loop frequency is f^,,^^ - f^tpp ^" ^mr '^^ 



reduce the capture time of the sum loop, a pretune voltage 
derived irorn the step loop's tuning voltage is summed into 
the sum loop integrator/filter. This pretune voltage guaran- 
tees that the sum loop's tuning voltage will produce an 
oscillation frequency near the step loop frequency. This In 
turn guarantees that the resultant difference frequency is 
within the range of the interpolation loop, so this loop will 
reliably achieve phase lock. 

The phase noise of the HP 3588A LO seel Ion in multiple- 
loop mode is typically -115 dBc/Hz for offset frequencies 



Adaptive Data Acquisition 



The HP 3588A spectrum analyser uses an adaptive data 
acqutsition scheme to opiimize system performance and respon- 
siveness. At the beginning of a sweep, a DIV1A coritroiter chip is 
set up to transfer 401 data points. As each new data point from 
the input channel becomes avaiiabie. a custom gate an'ay chip 
initiates the DMA transfer of the data point into matn memory. 
The measurement sequencer process periodjcaliy checks the 
contents oMhe DtvlA memory buffer as it HI is with new data .and 
sends aii newly arwed data as a block to the math coprocessor 
and the display process. 

System data processing and display time can be modeled 
roughly as follows: 



postprocessing time 



math and display time 

numberof blocks ^ overhead perbldck 



The math and display time Is the total time required to process 
and display ail 401 data points This time is essemialiy fixed 
However, transfemng data to the math coprocessor and to The 
display controller chip also carries with it a fixed overhead per 
biock, which is muitiptied by the number of data blocks sent to 
postprocessing 

Clearly, the lowest overall processing lime is achieved by send- 
ing all 401 data points at one time to math and dispiay On very 
fast sweeps, this is precisely what happens in the HP 3 588 A, 



When the measurement sequencer checks the DMA buffer, all 
of Ehe sweep data has already arrived, so one 401 -point biock 
is sent on for postprocessing and display. Thus, the analyzer 
Operates in its most efficient processing mode on the very fastest 
sweeps— when efficiency is most important, 

When the sweep is very slow, however, the total measurement 
time is dominated not by the postprocessing time, but by the 
sweep time. The adaptive data acquisition scheme serves this 
case equally well. Here, the data is only trickling into the DIvtA 
buffer. The measurement sequencer may check the buffer many 
times before finding any new points to process. Still, when new 
points do arrive, they are processed and displayed- in this way. 
the user is provided with a "'reaMime" update of the display trace. 

At moderate sweep rates, there may be many data blocks of 
ten or more points each. The adaptive data acquisilion scheme 
again tends to optimize overall system performance. In this case, 
if the postprocessing is slowed because of competing system 
activity (like ttie front-panel keyboard), the next data block will 
be proportionally larger This will tend to drive down the number 
of blocks per trace and thereby increase the postprocessing 
efficiency. 

James H. Cauthorn 

Development Engineer 

Lake Stevens Instrument Division 
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greater than 100 Hz, and spurious sidebands are typically 
better than -80 dBc. 

Source Section 

The HP 3 !iB8A includes a source wliose output frequency 
tracks the tuned receiver frequency and can be used as a 
stimulus for scalar network measurements. The source out- 
put frequency covers the full frequency range from 10 Hs; 
to 150 MHz at any user-selected output amplitude between 
10 dBm and -59.9 dBm with 0.1 -dB resolution. It is 
implemented on two printed circuit assemblies. The source 
block diagram structure mirrors that of the HP 3x5 B8 A 
receiver (sec Fig. 2). Development time was saved with 
this approach because several functional blocks were 
developed to be used in both the source and the receiver. 
These blocks include the 150-MHz low-pass filter, the 
310.1B75-MHz helical-resonator iF filter, and the step 
attenuator. Because the source and recei\^er share common 
intermediate frequencies, care bad to be taken that the 
source IF signal did not get into the receiver IF path and 
degrade performance. 

A 187.5-kHz signal from the HP 35B8A reference section 
is amplitude-limited and applied to the carrier input of a 
Gilbert cell multiplier. The second input to the multiplier 
i.s a dc control signal generated by a 1 2-bit digital-to-analog 
converter (DAC) and its associated trans impedance amp- 
lifier. The digital inputs to the DAC come from the main 
processor- The output of the multiplier is a square wave 
with an output amplitude controlled by the digital inputs 
of the DAC. This arrangement provides fine amplitude con- 
trol steps that fill in betw^een relatively coarse output 
attenuator steps. The user can access 10.9 dB of amplitude 
control range, and an additional b dB is available for source 
calibration, for a total of 25,9 dB of fine amplitude control 
range. The DAC provides adequate step accuracy over I he 
25.9-dB range. Harmonics of the multiplier output square 
wave fundamental frequency arc removed with a 190-kHz 
low -pass filter. The IBZ.S-kHz signal is mixed with a 
10-MHz signal from the reference section in an active mixer 
to produce a 10. 1B7 5-MHz IF signal. A crystal bandpass 
filter removes all undesired signals. The 10,1875-MHz sig- 
nal is then mixed with a 300-MHz signal from the reference 
section to produce the 310.1875-MHz IF signal. 

The 310.1875-MHz IF signal is filtered by a four-section^ 
coupled helical-resonator filter identical to the one used 
in the receiver's first IF section fsee description above). 
The 310.1875-MH2 IF signal is then mixed with the local 
oscillator signal, which ranges from 310.1875 iVIIiz to 
460.1875 MHz, to produce the lO^Hz-to-1 50-MHz output 
signaL Both the 3nD-MHz mixer and the output mixer are 
standard diode ring mixers with an LO drive level of 
7 dBm. A ninth -order 150-MHz low -pass filter removes all 
unwanted signals, such as mixer products, before the signal 
reaches ihe output amplifier. 

The output amplifier design was leveraged from a previ- 
ous product and consists of three sections.^ All three sec- 
tions are complementary, dc-coupled amplifiers with local 
bias stabilization circuitry. The first two are identical and 
provide 20 dB of signal gain each. Both series-shunt feed- 
back and shunt-series feedback are used in these two 
amplifiers to provide gain accuracy, good flatness, and con- 



trolled impedance over the full frequency range. The final 
section uses series-shunt feedback only and provides 15 
dB of gain at an output level as high as 11 dBm. A back- 
match resistor in series with the 15-dB amplifier output 
provides a 5011 output impedance. A servo circuit in the 
output amphfier samples the output \^oltage of the 15-dB 
amplifier and injects a correction signal into the first 20-dB 
amplifier to maintain the output at zero volts dc. Power to 
all three amplifier sections is supplied through shunt Zener 
diode regulators to prevent the output amplifier from 
degrading receiver or LO performance by corrupting the 
power supply at low frequencies. The 20-dB amplifiers 
also have private regulators. Following the output amplifier 
is a 50-dB step attenuator consisting of 10-dB steps. The 
step attenuator uses precision surface mount resistors and 
RF relays that maintain a coaxial structure internally. Mi- 
crostrip techniques are used to ensure good return loss 
over the full frequency range [the receiver step attenuator 
uses a very similar design). The overall flatness of the HP 
3 5 88 A source is typically ±0.5 dB. 

If an overload condition exists on the output connector 
that could damage the output amplifier and/or the step 
attenuator, an overload deteclor circuit disconnects the out- 
put connector from the source ontput. This source tripped 
condition is lalched and can be reset by the main processor. 
The sense point for the overload detector is on the output 
connector side of the protection relayt and a reset wiil only 
be allowed if the overload condition no longer exists. 

In addition to the main output, the HP 358SA source 
provides a signal path directly to the receiver for insti'ument 
self-test and source calibration, A portion of the source 
output signal is taken from the main output path ahead of 
the step attenuator to drive the swept calibrator. The HP 
3588A source can be turned off when not in use. Turning 
the source off disables the 187.5-kFIz limiter (which greatly 
reduces source IF levels) and disconnects the slep attenuator 
from the output connector. This minimizes any signal inter- 
ference that could corrupt a spectrum measurement, A 50- 
ohm load is connected to the output when the source is 
oft or when the direct source-to-receiv^er path is being used 
[such as during calibration). This provides the proper ter- 
mination impedance for any device the user may have con- 
nected. 

Very few adjustments are required for the source circuits* 
This reduces test time and the time required for periodic 
instrument calibration. The only required adjustments are 
on the helical-resonator bandpass filter. The four helical- 
resonator cavities can be tuned using DishaTs method,'* 
which is simple, accurate, and nonileralive. Tuning is 
facilitated by jumpers on the printed circuit board that 
allow reconfiguration of the IF signal path so that a signal 
from a sense port on the filter input cavity Is routed through 
the norma] IF path- No external test equipment is required 
for the tuning procedure on the source or receiver. 

Several features are included in the source circuitn' to aid 
in fault isolation. A detector is available to sense 187.5-ldiz 
signals and indicate their presence or absence to the main 
processor. An analog multiplexer allows main processor 
switching of the detector input to either the source 
lS7,5-kHz input or the output of the Gilbert cell multiplier. 
The threshold of the detector is such that a functional check 
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Help System with Hypertext 



HP's Lake Stevens Instrument Divisfon (LSlD) has included 
onHne help systems in i!s new analyzers fof the past sjx years 
All of these systems— including the HP 358aA's— are desig'^:: 
prlmarjly as online key references when the usef pmsscs a 
hardkey or a soflRey. tire anafyxer displays a description of the 
key's function, Ho-^A^vef, the HP 358BA's help system also 
includes two new features that meet the needs of a wider variety 
ot users; 

■ An index oJ help topics 
m Hypertext links between reiated topics 

How It Works 

The user enables the HP 3588A's online help system by press- 
ing the Help hardkey and exits by pressing While help is ena- 
bled, most of the analyzer s screen is dedicated to displaying 
help text; the rest of ihe screen cgminaes to display softkey labels. 

The analyzer provides some functions thai ailow the user to 
move around in the help system Most of these functions are 
assigned to hard Keys on Ihe numeric keypad A legend at the 
bottom ot the screen shows these assignments so the user 
doesn't have to remember them, The page is changed by press- 
ing 9 or 6. The index (see Fig. 1 ) is displayed by pressing 1 
Hypertext links are navigated by turning the knob and pressing 
4 or 7. 

Hypertext NavEgatlorv 

On a given screen full of help text, there may be several special 
words (or phrases) that are linked to related topics, The linked 
words are all underlined to distinguish them from the surrounding 
text {see Rg. 2) To select and display the topic Ihai's tinked to 
one of these words, the user turns the knob unlil the desired 
word is highiighted and then presses 4. After reading the contents 
of the new topic, the user can return to the previous topic by 
pressing 7 

The method used to display a finked topic is also used to 
display topics listed jn the index After pressing 1 to display the 
index, the user can turn the knob to highlight one of the listed 
topics and press 4 to display the contents of that topic. 
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A portion of the HP 358BA spectrun} analyzer's help 



Index Access 

In previous LSID help systems, a user could only access a 

key's description by enabling help and then pressing the key. 
These designs assumed that the user had already navigated the 
menu structure and was pondering Ihe use of a particular key. 
They worked well enough for e?<pe fie need users and for new 
users who like to locate funGiions by poking around on front-panel 
keys. They worked less well for other users 

The index provides a more systematic way for new or infrequent 
users to locate information about an analyzer function— including 
the name of the key that controls the function and the location 
of that key In the menu struclure- 

For example, to find out how to turn off the display graticule. 
a user can enter the help system, display the Index, and then 
look for an appropriate keyword, like "graticule " In this case, 



of the araplltiide control circuitry is made possible by using 
amplitude control settings above and below tbe detector 
threshold with the detector switched to the multiplier out- 
put. Additionally, the threshold of the source overload 
detector can be lowered by the main processor so that a 
lO-dBm signal will trip the overload detector. This is useful 
as an indication of source functionality and output 
amplifier bias faults. 

Reference/Trigger Section 

The refenmce/triggor section is partitioned among three 
printed circuit boards to minimise internal electromagnetic 
compatibility problems. The primary functions of this sec- 
tion are to provide the various UHF, \rHF, and LF references 
used by other sections of the instrument, and to provide 
the in.Htmment synchronization and trigger logic. Fig. 4 is 
a block diagram oi the reference /trigger section. 

The HP 358BA can free-run on its internal 80-MHk VCXO, 
lock to an optional 1 0-MHz oven referencen or lock to a 
user's refenmne at IfJ/N MHz, where N is an integer from 
1 to 10. Thi* BO-MHz VXGO is designed to have low temper- 



ature drift and good stability for users who do not require 
the high performance of the optional nvenized reference. 
The 8U-MHii reference is used to provide quadrature ZO-MHz 
clocks for the digital filters, using a Johnson counter on 
the same circuit board as the filters. 10-MHz references are 
derived from the aO-MHz VCXO and are used in various 
places throughout the instrument- 

The 300-MHz reference is an LC oscillator that acts as 
the LO for the second conversion and provides an offset 
frequency in the LO step loop (see Fig. 3), With this 
architecture, the net phase noise caused by the 300-MHz 
reference is: 

[300-MHz phase noise) x (1 - H^^pHsur^)- 

where H^j^p and H^„^i are the closed -loop phase transfer 
functions of the step and sum loops, respectively (with the 
gain of the step loop normalized out). 

This effectively high-pBSS filters the 300-MHz phase 
noise (in the offset frequent;y domain] and provides altenu- 
atjon at low offset frequencies. Thus, the requirement for 
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Rg. 2. Words in help text that are linked to related topics 
are underlined. 

the user would find the entry "Graticule On/Off soft Key /' When 
the entry is selected, the analyzer displays text describing the 
key. The text also contains a key path, which indicates the location 
of the key in the menu siructure. 

Related Topics 

in a complex product like a spectrum analyzer, one key's func- 
tion is often closely related to another key^s function. A user 
needs to understand such relationships to use the analyzer nnost 
effectively, Hypertext tinks make Ft easy to explore reiationshfps 



by allowing a user to move directly betweeri related topics. 
For example^ the help text that describes I he Ejcternal Trigger 

softkey points out that the analyzer must be armed before it can 
be triggered. In Ihis text, the word ''armed"" is linked to the topic 
"Arm Auto/Man softkey." which describes arming. The user can 
move dfrectly to the topic on arming by selecting the word 
"armed. " 

N on -Key Topics 

Since the HP 3588 A help system allows access to topics via 
the index and links, 1! is possible to include topics that are not 
bound to a particular hardkey or softkey. We have taken advan- 
tage of this new freedom to create independent topics that define 
commonly used terms. Any time we use one of these terTns in 
the help texi. we link the term to its definition, Definmg t^rms in 
independent topics has two advantages: 
■ Users who don^t know what a term means -typically novice 
users— can simply select the term and display the topic that 
defines it. This allows all readers to have a common under- 
standing of the temns used in help topics. 
• Users who already know what a term means— typically expert 
users —don 'I need to read Its definition each time the term is 
used. This reduces the information clutter presented to these 
users, making it easier for them to find the information that 
they really need, 

As a side benefit, this approach allows the help-text writer to 
define a term only once. This reduces both writing time and the 
storage space required in the anatyzerfor online help. 

Mark M. Smith 

Learning Products Developer 
Lake Stevens Instrument Division 



spectral piiritv of thn 30n-MHz reference at low offset fre- 
quencies is eased by this effect, allowing the use of an 
inexpensive LC oscillator ratiier than a more expensive 
low-noise oscillator oinploying a SAW [surface acoustic 
wave] resonator. 



Low-frequency references are provided for the source 
(187,5 kHz), the ADC sample clock (250 kHi^). and the 
interpolation loop reference [100 kHz). Synchrnnization is 
maintained between al! these references and the Start_Meas 
signal so that data taking and the LO sweep are syn- 
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Fig. 4, HP 35mA reference sec- 
tion. 
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chioiiized and repeatable. 

Further s\T2cliJGnization capability is provided so that 
several HP 3588A*s can be configured to sweep synchro- 
nously, within a few microseconds uncertainty, using an 
BASIC application program. This allows synchronized 
offset or harmonic sweeps, fecilitating mixer or generalized 
distortion testing. To achieve this, the synchrDnizing cir- 
cuit allows the low-frequency references and Start_Maas 
signal of all instruments to be STOcbronized through a Trig* 
gef Out signal provided on the rear paneL 

Speed Advantages of FFT-based Spectrum Analyzers 

For several decades. Hewlett-Packard has offered spec- 
trum analyzers using FFT technology in the baseband fre- 
quency range up to 100 kHz. The FFT is used essentially 
as a bank of parallel bandpass filters. Since all the Bhers 
settle and measure simultaneously ^ the measurements can 
be much faster than with a swept filter of similar resolution. 
This Is very usefiil for transient signals and time-varying 
signals, so this technique has been termed "dynamic signal 
analysis". Typical window functions de.5igned for ampli- 
tude accuracy are three to four FFT frequency samples 
wide. A 512-poinE FFT thus provides over a hundred par- 
allel filters at once and may provide measurements over 
100 times faster than a single analog filler. 

Swept analyzer measurement speed varies dramatically 
with different shape factors when the need to resolve close- 
in spurs is considered. For the purposes of this discussion. 
a close-Lo spur is a signal to be analyssed tbat is very small 
and very close to a much larger one. The intent, of course, 
is to resolve the spur as a spectral component* independent 
of the large signal. To resolve these spurs, a filter with a 
larger (worse) shaj>e factor must be set to a much smaller 
nominal 3-dB resolution bandwidth than a filter with a 
better shape factor. Otherwise, the spur just disappears 
into the skixt of the large signah In a swept spectrum 
analyzer, the sweep time variation must he Inversely pro- 
portional to the square of the resolution bandwidth. If a 
filter with a poor shape factor has to have one-third the 
3-dB bandwidth of a better filter to resolve the desired 
signal, the sweep time will be nine times longer. 

The speed advantage of FFT spectrum analysis over 
swept filter analysis is even more apparent m the close-in 
spur case. The FFT windows typically used have shape 
factors of 2.6:1 , which is much better than the typical swept 
resolution bandwidth filter spec ificat ion. which ranges 
from 11:1 to I5;T Thus, with both the basic FFT speed 
improvement and the speed irn prove me nt from the im- 
proved shape factor, an FFT mmlyzer can be many hundreds 
of times faster than a traditional wide-shape-factor analog 
swept analyzer for small, close-in signals. 

FFT analyzers have been used in down-converted sys- 
tems to gain the advantages of FFT measurements at higher 
frequencies. An example is the FEP 3 04 8 A phase noise mea- 
surement svstem. tvhich uses a dynamic signal analyzer to 
measure phase noise rapidly at offsets up to 100 kHz for 
carrier frequencies up tti 1 B GHz. 

The narrow liand zoom measurement mode of the HP 3588 A 
uses FFT analysis to provide quick measurements for fre- 
quency spdns up tn 40 kHz. The center frequency can be 
a n y w h ere i n tti e i n s t r u m e n t ' s freq u o n cy ra nge . The instru - 



ment updates the 40- kHz span more than seven times per 
second, and provides frequency resolution better than 
400 Hz. Many measurements that were not really possible 
before are now fairly easy. 

For instance, it is possible to watch modulation 
sidebands move as the modulation frequency- changes. Dur- 
ing development of the HP 3588 A, this capability was used 
to improve the 8O-MH2 crv'Stal reference oscillator. One 
HP 35B8A was vibrated on a shaker table that was being 
driven by a swept frequency ramp, and a second HP 3 5 88 A 
analvzed the output of the first. The real-time presentation 
of the vibration- induced oscillator sidebands allowed diag- 
nosis of the chassis and printed circuit vibration modes 
and subsequent suppression of those modes. Previously, 
it was difficult to see the modulation sidebands move as 
the table stimulus changed. 

improved FFT Dynamic Range 

I'sers ot traditional swept analyzers often reduce the 
resolution bandwidth to lower the noise floor to analyze 
smaller signals. The noise sources in the input circuits of 
the instrument are typically the limiting factor in low-level 
signal detectability. If the resokition bandwidth can be low- 
ered enough, thereby lowering the noise bandwidth, signals 
can be inspected that are over 100 dB below the input 
range of the instrument. The user trades off slower measure- 
ments for mare dynamic range. A 32-bit FFT is used in die 
HP 35 88 A to allow this same trade-off. Reuse of the proces- 
sor board from a previous design meant the reuse of the 
16-bit math coprocessor (a Texas Instruments TMS?12UC25), 
and the reuse of much of its firmware. Firmware xvas avail- 
able to do all the fundamental math operations. A well- 
characterized 16-bit FFT was also available. This certainly 
meant faster developmenlt but the l(^^-bit FFT did not have 
enough dynamic range to reduce the noise floor adequately. 
Because of headroom and windowings the 16-bit FFT was 
good to about 90 dB of dynamic range. A 32-bit word -length 
FFT was written s[ieciiicaliy for the HP 35fJ8A. This FFT 
provides spans of less than 100 Hz, at wdiich the instru- 
ment's displayed noise floor is 120 dB or more below the 
input range. This allows the sijnultaneous analysis of a 
carrier at or below the range and a spur a few hertz from 
the carrier frequency at 120 dB below the range. 

The computation of a 32-bit FFT is considerably slower 
than a 16-bit FFT. However, the dynamic range obtained 
with the longer- wordTength FFT is deemed worth the 
resulting decrease in speed. The speed of FI^'T measure- 
ments with narrow spems is dominated by the time required 
to acquire the time record. Wide-span FFT measurements 
run at over seven updates per second. 

Sweep Dynamics and Corrections 

The rt^solution fi Iters in the HP :J588A*s final IF section 
can be swept at rates four times faster than traditional, 
synchronously tuned filters of the same resolution band- 
w^idth. The HP 358SA automatically corrects amplitude and 
frequency errors resulting from these fast sweep rales. This 
technique allows the HP 3 5 88 A to make swept measurements 
much faster than previous swept spectrum analyzers. 

The goal of the resolution filter is lo select a narrow band 
of frequencies and reject all others. The energy in the 
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selected band is detected and passed to the main processor 
for subsequent display* The resolution filter is defiiied by 
its resolution bandwidth, which is its S-dB bandwidth. 
When the analyiKer is tuned to a signal, a heterodyned ver- 
sion dF the signal is inside the resolution bandwidth and 
is detfjfjled. When the analyzer is tuned aw^ay from the 
signal, the heterodyned version falls outside the resokition 
bandwidth and should not b*^ detected. However* the sig- 
nals are actually moving in frequency as the local oscillator 
is swept. Therefore, the filter must respond quickly and 
accurately to transient signals. The filter should respond 
with an accuracy of 0,1 dB to all these swept signals, with 
no ringing or overshoot. The traditionai approach to reso- 
lution filter implementation is to approximate a Gaussian 
frequency response using a synchronously tuned filler, 
which is a cascade of several identically tuned filter stages. 

The result of sweeping traditional filters much faster 
than the traditional maximum rate (one lialf the square of 
the resolution bandwidth) is to distort the spectrum display 
in several ways {see Fig. 5], Two Brst- order distortions are 
expected since they appear when the theoretical Gaussian 
filter is analyzed. One first-order distortion is a monotonic 
decrease in response amplitude as the sweep rate is 
increased, The amplitude error rises dramatically and 
unacceptably for sweep rates faster than the traditional 
maximum sweep rate. However, the amplitude error is min- 
imal for slower sweep rates. Another first -order distortion 
is a displayed frequency shift to the right. The perceived 
frequency shift is equal to the group delay of the IF filters 
times the sweep rate. Therefore, if the analyzer is swept 
four times as fast, the displayed signals shift four times as 
much. 

Sweeping traditional filters too fast also has some 
second-order distortion effects (see Fig. 5). For example, 
the amplitude response becomes very asymmetiical about 
the peal^ of the response. Both edges uiay also exhibit 
notches and ringing rather than a smooth transition 
between the noise floor and the signal peak. These distor- 
tions are unacceptable because they may conceal spectral 
features of interest to the spectrum analyzer user, such as 
spurs or modulation on the large signah The combination 
of all these spectral dislorlinns has limited analyzers with 
traditional filters to the maximum sweep rate limit of one 
half the square of the resolution bandwidth- 
Analysis of the response of an ideal Gaussian filter to 
swept-frequency input signals shows only the amplitude 
decrease and the frequency shift. Both of those distortions 
in the response are perfectly predictable. However, the 
analysis of the ideal Gaussian filter shows none of the 
second-order effects apparent in traditional implementa- 
tions. Thus the accuracy of the traditional filter approxima- 
tion is inadequate for faster than traditional sw^eep rates. 
However, there are advantages to sweeping faster than the 
traditional sweep rates. 

It can be shown by analysis of the ideal Gaussian filter 
that for a fixed sweep rate, a range of resolution band widths 
narrower than that traditionally chosen for that sweep rate 
actually provides belter frequency resolution. For a given 
sweep rate, there is a bandwidth that gives the finest reso- 
lution. This bandwidth Is commonly know^n as the 
optimum resolution bandwidth;^ For a fixed sweep rate, 



the signal'to-noise ratio is maximized when the resolution 
bandwidth is set to its optimum value. This signal-to-noise 
ratio is almost 2 dB better than at the traditional bandwidth 
for that sweep rate*^ 

I'he HP 35BBA uses a digital, linear-phase, resolution 
bandwidth filter in its final IF section, )ust as in traditional 
implementations, the amplitude response decreases and 
the detected trace shifts right as the sweep rate increases. 
However, the HP 3 588 A is able to correct these first -order 
distortions completely (see Fig, 6), The decrease in 
response amplitude is purely a function of tlie sweep rate 
and the filter bandwidth. The amplitude decrease is cor- 
rected by predictmg the loss and applying a compensating 
gain. Unfortunately, the resolution bandwidth filters in tlie 
HP 35B8A are not ideal Gaussian filters. In fact, their 
response is not close enough to allow use of theoretical 
Gaussian response calculations for correction values. 
Instead, the software holds a two-dimensional table of 
calibrated amplitude loss, indexed by sweep rate and reso- 
lution bandwidth. The expected decrease is interpolated 
from the table for each measurement setup and inserted 
into the composite correction trace for the measurement. 

The right shift in the detected data is also predicted and 
corrected. Since botli the group delay in the IF path and 
the sweep rate are known, the amount of frequency shift 
is easily calculated. This shift is corrected by shifting the 
detected data Mi by an equal amount. 

Spectrum analysers using traditional filters could con- 
ceivably correct the first-order distortions much as the HP 
3588A does. Many users already do so to some extent. For 
instance, sophisticated users are aware of the frequency 
shift and mentally correct that themselves. There seems to 
be no way. however ^ to correct the asymmetry between the 
rising and falling edges and the ringing in the edges of the 
response. If those distortions are still present, there is noth- 
ing to be gained by correcting the first-order effects. 

The resolution filters in the HP 3568A digital IK do not 
have the second-order distortions apparent in the tradi- 
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lional implementations. Since they are FIR filters with, per- 
fectly linear phase, the falting edge of the response is just 
a mirror image of the rising edge of the response. Especially 
important is that the edges of the response are smooth. 
with no ringing (see Fig. 6), 

Firmware Implementation 

The Hrmvvare controlling I he HP 3 588 A spectrum 
analvxer supports a rich set of features for the setup and 
control of spectrum analysis measurements. In addition ^ it 
offers a range of higher-level capabilities, including: 

■ Optional HP instrument BASIC 

■ HP-IB controller capabilit\^ 

■ Programmable limit testing 

■ Online help 

■ Programmable "user math" postprocessing operations 

■ HP Test and Measurement Systems Language (TMSL} 
compatibility* 

■ Internal file system for storage of traces, states, and pro- 
grams 

■ Optional internal disk drive. 

Some of these features have never before been available 
in a swept spectrum analyser. 

^ITieHPTesjanrdMeasfiremenlSysteiTis.Lafigfjage (TMSLJ isthetjs^.is for rhenewStanasrtJ 
Ccmmands foT Program[TaE>!& tnsfrurramts tSCPi) standaro. 



User Interface Compiler 



The user interface compiler (uic) is a lool designed to increase 
me productivity ot software engineers and to aid in the documen- 
tation of the user interface for the people who use. test, and 
implement it On the HP3580A project, this lool helped to make 
the user interface more consistent. U also greatly reduced the 
lime needed to make modifications and significantly reduced 
errors in documentatron. 

The uie software too] reads an input file containing a description 
of the user interface and generates several outpul files. The input 
file contains a sequence of keywords followed by relevant infor- 
mation in a fa^^ly flexible format, The different keywords rndicate 
definitions for soflkeys, menus, and HP-IB commands and 
parameters. There are also fie Eds for a key's functional descrip- 
tion, the name of the engineer responsible for thai description, 
the help text associaled with ihe key. and the HP- IB command 
associated with the key. 

The output files include the following informatron: 

■ C data structures that are downJoaded into the analyzer 
m The HP- IB language free (hpsbtree) 

■ The BOftkey menu tree (keytree) 

■ A iist of all HP-IB commands for automated testing (hpibieaves) 

■ Help text that is downloaded into the analyser 

■ Customer reference manuals tor both the front panel and the 
HP-IB 

• Internal technical references for both the front panel and the 

HP-IB. 

The various descripf i ve paragraphs in Ihe input file are targeted 
to a particular output file or files through the use of dsfiereni 
keyvi^ords It is also possible to include the help text descnptions 
in one or more of the generated documents, 

The most notable output file contains the C data slruclures 
that represent the entire user interface. The contents of this file 
represent the menu structure, parameter information, configura- 
tion data, and HP- IB language for the analyzer Thesa data struc- 



tures are used by a state machine called the front-panel kernel, 
which realizes the front-panel interface for the analyzer An HP-IB 
parser implements the bus control for the analyzer, using the 
uic-generated data structure file. These files can be compiled 
and linked together with the rest of the analyzer firmware to 
create the analyzer executable code. 

Several documentation files can be generated by the uic. Some 
of these files contain detailed descriptions of the commands, 
others contain summary information. The hpibtree and keytrss files 
are examples of summary files. Hpibtr&e shows the enttre HP- IB 
language understood by the analyser in a form that portrays the 
hierarchical nature of the HP Test and Measurement Systems 
Lang uage Keytree shows al I softkey men u s a n d t h e i r rel a t i on sh i ps 
to each other as well as the equivalent HP- IB commands for 
each softkey 

Other documentation files contain more detailed information. 
The front-panel external reference specification (ERS) contains 
a description of each softkey and describes the parameters, the 
responsible engineeJ'. and how the softkey interfaces !o the rest 
of the analyzer, Traditionally, a similar documeni has been the 
only description of the user interface available until the technical 
writers finish the customer reference manuals. Another docu- 
ment, the HP-IB ERS. describes similar informatton for each of 
the HP-IB commands These two files are considered internal 
information and are intended to be used by software and 
hardware engineers, test engineers, technical writers, and man- 
agers 

The UIC also generates files that can be used as prototypes for 
fronl-panel and HP-IB customer reference manuals. These files 
contain refined descriptions of tunctionality and omit implemen- 
tation details. 

The hprbleaves uic output lite has proved to be very valuable in 
testing the analyzer. This file includes only the HP-IB commands 
that have execution routines associated with them. Listed with 
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each eommand are the required and optional parameters, includ- 
ing I he range of accepted values for each numeric parameter. 

Tests have been written that parse this file and send commands 
in either a random fashion or sequentially to verify thai all of the 
analyzer's HP- IB commands function properly. 

In additran to these output files, ihe u\c provides an extensive 
set of diagnostic warnings and errors These provide information 
about problems and potenliaJ problems with the user interface 
description. 

The key to the user interface compiler's benefit is that it pro- 
vides a single point of controJ for the user interface definition. 
The uic's input file coniams all of the information required to 
generate the documents described above automatically. Thus, 
changes made in key labels, actions, or definitions during 
ftrmware development are immediately reflected in the front- 
panel and HP-IB user interfaces, m all versions of the documen- 
tation, and in the automated test documents. Having a ssngte 
point of control, coupled with automatic generation of important 
files, means that the user interface and its documentation are 
more up-to-date and reliable throughout the product s develop- 
ment cycle. This translates into a considerable productivity gam. 

As an example of this productivity gain, consider making a 
simple change to an analyzer's user interface definition during 
development, such as adding or deleting a soflkey. Making such 
a change on our previous generation of analyzers would typically 
take two to Lhree person-days to complete. The change proces^s 
involved editing several files that variously contained information 
about the key's operation, its associated documentation, help 
text, and automated test files. Using the uic. a simifar change 
takes only 15 to 20 minutes because all of the associated files 
are generated from the single vie input file. Given that our recent- 
generation analyzers have typically contained many hundreds 
of key and HP- IB mnemonic definitions, the potential for time 
savings is great. 

Another problem with maintaining the user interfaces of previ- 
ous analyzers throughout their development phase was that all 



changes required the attention of software engineers. This was 
because the majority of the information was buried in C source 
files. The uic allows a nonprogrammer to maintain the user inter- 
face On one current project at the Lake Stevens Instrument 
Division {LSID), a technical writer and a software engineer share 
the responsibility of maintaining the ujc's input file. Also, the uic 
makes it possible for marketing engineers or project managers— 
who are chiefly responsible for the analyzer's functional defini- 
tion—to maintain the input file and hence the user interface. 

Using the uic. an analyzer's entire user interface can be pro- 
totyped very quickly. The prototype of the user interface can be 
provided even before analyzer hardware is available. One LSID 
project has made an X Window System host version of the 
anatyzer front paneE, which allows, a large portion of analyzer 
code to be developed on the host without havmg to use the 
target hardware Because the ufc assumes a generic interface 
to the analyzer state control code- it is not necessary for that 
code to be aware of the menu structure, except where there are 
variant menus that depend upon thecurrent state of the analyser. 

Often the user interface data structures developed dunng the 
prototyping phase of a project have to be reworked and main- 
tained constantly during tfie project's development cycle. With 
the uic. this effort is reduced to maintaining the ufc's input file. All 
of the key user interface data structures are then automatically 
generated. 

The user interface connpiler was developed ar^d evolved during 
the development of the HP 35S8A During that time, it matured 
into a tool whose output was relied upon by a diverse spectrum 
of project personnel. It saved hundreds of hours of development 
time on the HP 3588A project and helped to create a more 
reliable and consfstent product. Today it Is being reused on many 
projects- at several Hewlett-Packard divisions- 

Bryan P. Murray 

Development Engineer 
Lake Stevens Instrument Division 



Iiriijleinenling these features was not the only challenge 
to the design team. Another requirement was to reuse the 
main processor board, front panul, and display from an 
earlier low- frequency FFT-based analyzer. The processor 
board contains a dedicated TMS320C25 math coprocessor. 
This coprocessor, along with synthesized sweeping capa- 
bility and a fully digital final IF stage, makes it possible 
for the HP 3 588 A to integrate traditional, broadband, high- 
frequency swept spectrum analysis with the excellent 
speed and resolution of FFT-based analysis. The math co- 
processor also enabled us to include limit testing and exten- 
sive user math capability. 

The reuse of the CPU board brought Its own challenges, 
however. The board was basically designed to support the 
block-mode data processing that is characteristic of an FFT- 
based analyzer. The HP 35B8A presents a serial data stream 
to the CPU board. It w^as therefore a challenge to use the 
available hardware to present sweeping data on the display. 

In addition, the firmware system designed for the earlier. 
FFT-based analyzer could not meet the performance 
requirements of the HP 3588A. With the exception of some 
leveraged hard ware drivers, the team essentially had to 
start the firmware development from scratch. As usual, 
this was all undertaken in the face of very ri^id time-to- 
market constraints. 

The code was written primarily in C on HP 9000 Series 



300 w^orkstations interconnected over a LAN. Each 
engineer had a prntotype analyzer which was used for 
software development and testing. The target system 
(analyzer hardware) consisted of an MC6H000 CPU, the 
TMS320G25 math coprocessor, and auxiliary processors 
used in controlling the front -panel keyboard. HP-IB, CRT 
display. DMA. internal disk drive, and interfaces to the 
various analyzer hardware boards. During development, 
the designers w^ere able to download executable code froni 
their workstations into the target system. Execution of the 
txxle in the analyzer was controllable through a source- 
level debugger running on the workstation, The final 
firmware system consists of approximately 107 thousand 
lines of source code» occupying approximately 1.2 mega- 
bytes of ROM. 

One of the first key decisions was to use p SOS* as the 
kernel of our real-time, multitasking operating system. 
Most previous analyzer projects Irom our lab had invented 
their ov\n operating system kernels. pSOS provides a small, 
reliable, and efficient real-time kernel. By picking an off- 
the-shelf product, we avoided most of the development, 
debugging* and quality assurance time we would have 
faced had we developed a new operating system kernel. 

We also accelerated the project by adopting an existing 
SCPl-compatible HP-IB parser fern Hewlett-Packard's 
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Measurement Systems Operation. The HP 3588A has over 
300 softkeys and recognizes over 200 HP-LB commands. 
To ease the coding burden of such a large system, one of 
the designers developed an automatic code generator that 
produced all of the necessarj' data structures and much of 
the documentation for the entire user interface. 

High-level analyzer operation was hroken out into five 
prirpaiTk* processes: user interface, measurement manager, 
measurement sequencer^ display manager* and Instrmnent 
BASIC. Other processes were allocated for such purposes 
as parsing HP -IB input, trace plotting, and other system 
utility functions. Each designer was assigned responsibility 
for one of the primary processes and certain auxiliar\' tasks. 
Then, interprocess communication requirements were 
determined. 

At this point, the design team had estahlished a simple, 
modular design with clear requirements and division of 
responsibility. These factors contributed greatly to rapid 
development time by allowing work to proceed at different 
rates in each of the Vtirious project areas. During the course 
of firmware dev^elcprnenl. it was unusual for any designer 
to be held up waiting for another to complete some task. 



pling and qualification before entering new values into the 
analyzer's master state data structure. After the master state 
is updated, the instrument state module informs the mea- 
surement manager and the display manager processes that 
a certain type of state change must occur. This interprocess 
communication occurs via messaging over a pSOS exchange. 
If the changes require updating the data scaling or calibra- 
tion constants, then the niath manager module is aJso 
informed. Once all the specific change command messages 
are sent, the user interfece process terminates, allowing 
the measurement and display manager processes to become 
active. These processes effect the desired changes. When 
the hardware setup and display scaling and format are 
consistent with the master analyser state, the measurement 
manager process becomes inactivct aw^aiting further change 
command inputs from the instrument state module. 

The measurement sequencer process then reactivates, 
resuming data acquisition. The display manager process 
converts from a dynamic change management operating 
mode to a relatively quiescent mode of drawing trace data 
and annotation on the display. At this point, the analyzer 
has resumed its stead y-state operating mode. 



Firmware Architecture 

Fig. 7 show,s a conceptual block diagram of the firmware 
organization. In the figure, the rcctangiilitr blocks represent 
pSOS processes, the oval blocks are major modules tliat do 
not run in a unique process, and the shaded blocks are major 
data stores. Interprocess communication fakes place via 
pSOS message passing and proce.ss signaling mechanisms. 

When the analyzer is not pror:essing inputs from the front 
panel, HP -IB. or Instnmient BASIC, only two of the system's 
processes are generally active: the measurement sequencer 
and the display manager. This condition may be thought 
of as the steady 'itate. In this mode, interprocess communi- 
cation and swapping are minimized. This helps system 
performance find keeps the firmware operation relatively 
simple. 

During steady -state operation, tlie measurement sequencer 
manipulates hardware and oversees the data ^acquisition 
required during each measurement loop. It passes newly 
acquired data to the math manager module, which executes 
physical coprocessing within the TMS320C25 chip. The 
measurement sequencer process is then free to continue 
acquiring new data while the postprocessing and display 
of previous data are underway. Math operations include 
calibrated data correction, display scaling, user math oper- 
ations, and limit checking. When the math coprocessor has 
completed its operations, it interrupts the CPU to awaken 
the display manager process, which then routes the pro- 
cessed data to the display- 

When a front- panel key is pressed, or when HP- IB com- 
mands arrive from the external bus or from an hidtrument 
BASIC program, the firmware goes into a dynamic change 
management mode. These inputs are first detected in inter- 
rupt service routines. These, in turn, activate the user inter* 
face process, which preempts the measurement sequencer 
and display manager processes. The key codes or HP-IB 
commands are then directed through the instrument state 
module. 

The instrument state module performs parameter cou- 



Firmware Quality Assurance and Reuse 

Several UivAors considerably increased the effectiveness 
of nur quality assurance effort on the firmware. First, we 
kept our design solution proportional to the size of the 
problem. This resulted in a reasonably simple, robust 
firmware svstem thai was well -under stood by the entire 
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Fig. 7. HP 3588A firmware block dfagram. 
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team. 

Second, we implemented a very extensive automated 
testing system. One of the outputs of our user interface 
compiler [see '*User Interface Compiler/' page 57) was a list 
of every HP-IB mnemonic that the analyzer can recognize. 
This output file was used as a data base for a genera iii^ed 
computer-controlled random codes test, which attempted 
to cause the analyzer's firmware to fail, In past projects, 
the random codes test required months to design and hours 
per week to maintain. Our system was thorough, always 
up-to-date, and required virtually no maintf^nance. 

Third, the HP 3 588 As internal Instrument BASIC capa- 
bility provided a very conyenient way for the designers to 
de%'elop test programs. These programs were kept on stan- 
dard 3 '/2-inch diskettes, whirjh were easily moved between 
prototype analyzers. These programs served both as regres- 
sion tests and as debugging and verification aids. 

The firmw^aie system developed for the HP 3 58 8 A has 
already been extensively reused on three projects at the 
Lake Stevens Instrument Division and one project at the 
Network Measurements Division. The HP -IB controller 
code has been reused by five local projects and by the 
Colorado Springs Division, the Spokane Division, and the 
Yokogaiva-Hewlett-Packard Insfrumenls Operation (YIO). 
The user Interface compiler is in reuse on virtually all local 
projects and a[ YIO. 
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"•• Calc m the HP 75 cal- 
\ ^ \ culator. FORTH m the HP 

7 1 c aJcu lator . oper at i n g systems i n ( h e H P 28 a n d 
HP 4eSX calculators, and Equation Writer in the 
HP48SX calculator Hejoined HP'sCon/allis Divi- 
sion in 1991 as 3 software engineer. His eclectic 
in teresis are reflected in his education — a BA de- 
gree {1 974) in religious studies at the University of 
Michigan, and a PhD degree (1 979) in philosophy 




amJ a BA ci^jee ( 1 981 ) in computer science at the 
Unhrsfsity of Tejtas He is r^rued an inventor in a 
patent pendng tor the HP 48SX EquatJonWnter ap- 
piicatHsn arrd a co^nverrtor m a patent on caScuiatofs 
With a ijser-acoessitHe object stack Bom in 
Chicago, Hi mots, Gabe Ives m COh/allis, Oregon, 
and enjoys backyard asironomy, attemahve music, 
ami sk'ing, 



Patrick J. Megowan 

'/dHirtg computing acces- 
:; Die. relevani. and 
TeAardcng to people is the 

professional goal of Pal 
rv!'egowan. whojo'oed HP's 
Corvair«s Division in 1961 
He designed and de- 
veloped the solve, plot, 
I Stat, time, ana lO applica- 
I tionsfortheHP4BSXscien- 
tiSic calculator, and helped design is general ap- 
plication structure, keytjoard, and screen layout. 
Pat also helped design the HP 41 , 1 BC, 1 9B, 27S. 
1 7B, 20S. 1 0S, and 21 S calculators. Before joining 
HP, he developed pattern recognition software at 
the IBM Federal S/stems Division. A 1 979 graduate 
of the California Polytechnic State Unsversity at San 
Luis Obispo, Pat earned a BS degree in mathemat- 
ics, and has done postgraduate work ^n computer 
science at the University of California at Santa Bar- 
bara and in physical geography at Oregon State 
Un i versf ty Pat f s active i n co m m u n i ly p I an nl ng an d 
land use issues around his hometown. Corvatlis. 
Oregon He is married, has two daughters and a 
son, and enjoys natural history, rock climbing, tele- 
marKing, and playing the violin, mandolin, and 
guitar. Patcompetesm treestylebtKe trials, collects 
and cultivates trees, and "moonlights" in architec- 
ture and landscape design 




22^ HP Sotva Equation Ubraryl 




Erie L. Vog#l 

R^D software project man- 
ager Eric Vogei joined HP 
while he was still a student 

in 1 976 when HP's Corvattis 
Division first opened Ha 
earned a BS degree in 
mechanical engineering 
^■:Mvi Oregon State Univer- 
!/n1978,and was hired 
on a permanent basis as an 
app(icati;-;ii'- ,1 ■ ^ r in 1980. Ehc developed appli- 
cation snfiwartf ?of the HP 41 and HP 75 calcu- 
lators, and served as a lead sottware engrneer (or 
the operating system and development tools tor the 
HP 94 indusiriaf computer. He also helped test and 
develop the HP 1 7B, HP 1 98. HP 27S, and HP 20S 
calaulaiors, and was a project teader and then proj- 
ect manager for development of the HP Solve 
Equation Library card lor the HP4eSX scientific cal- 
culator The author of owner and reference manu- 
als for calculator products and a collection of pe- 
troleum reservoir engineering programs, Eric is 
named as a co inventor m patents pending tor cal- 
culator unit management techniques and the Mul- 
tiple Equation Solver Born in Los Angeles. Califor- 
nia, he lives in CorvaHiS, Oregon, is marned, and 
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has two sons and a daughief. He enjoys gcl^f, 
foreign travel, reading, woodworking, anc) remod- 
elrng his house. 



25 ^ HP 4SSX Hardware D«sfgn : 




I A. Smith 

Mark Smtih pined HP's 
Corvallis Di\/ision in 1 980. 
stioflly after receiving his 
B3 degree in mechantcaJ 
engineercng from tine 
CaiiforniaPotytechnfc State 
Universily al San Luis 
V,"''1 Obispo As an R&D 

mechantcaJ er^gineer, he 
helped develop the HP 
4eSX caJculator and also workect on the HP 1 DC, 
15C, 16C, 75D. 1BC, 28C. 19B. and 283 cal- 
culators. A licensed p rotes si on aJ engineer, he has 
authored ariides an the mectnanicaf dBSign ar^d 
hinge interconnect design of the HP 1 BC and 
HP2BC catcuiators. Born in Uverrnofe, California, 
he lives in Carvallis. Oregon, is married, and has 
two sons. He enjoys skiing, dirt bike riding, and 
coaching a youth soccer team- 



Lester S. Uoore 

Les Moore joined HP in 
1959 after serving In the 
US Air Force irom 1955 to 
1959 He graduated from 
San Jose City CoMege in 
1 955. An electronic design 
engineer with HP since 
^^^^ t959, Les has worked on 

-^i'^'^H^^^ the HP 65, HP 45, HP 21. 
_' mk ^^B^^ arid HP 28 afcu Gators, and 
produced the sysiern dessgn for the HP 48SX sci- 
enlrfic caEOulator Born ^n San FranciBco. California, 
he lives in Corvallis, Oregon, is married, and has 
three grown children Les enpys gardening , grow- 
ing orchids, woodworking and growing koi fish in 
a 4.000-gailon fish pond. 



James P^ Dickie 

Hardware project n^anager 
Jim Dickie joined HP's Cor- 
vallis Division shortly alter 
receiving a BSEE degree tn 
1 976 from Arizona State 
University He earned an 
MSEE degree m 1 983 from 
Oregon State Universily. 
Jjm was the profect man- 
ager for the electrical and 
mec h a n I ca i sy a E ems f or rhe H P 4eSX ca I cuiator. He 
designed tne microprocessor for ihe HP 71 cal- 
culator, and helped desjgn the HP 59C calculator 
and [he Series EfC caiculaior family He is named 
an invenior m a patent on the architecture of the 
HP 71 microprocessor Bom in San Diego, Casifor- 
nia. Jim was raised in Phoenix, Arizona, and lives 
in Corvallts, Oregon. He ts married, has three 
children, and enjoys running, pfaying softball. ski- 
(ng, reading, and coaching youth soccer 






Preston D, Brown 

Soon after graduating from 

rhe University of Florida 
with a BSEE degree In 

1981. Preston Brown joined 
HP's Corvatiis Division as 
an R&D engineer, He was 
respor^sjble for custom IC 
and system design for the 
I ^ ^ HP ThinkJet printer and the 

i-^ r HP4lCV,4lCX.^aC.20C 

1 9B, 2SS, and 4BSX calculaiors. A member of the 
IEEE and the AAAS, Preston is the author of confer- 
ence artFGles on pattern matching and a disppay 
driver. Born jn Pensacola. Florida, he lives in 
Eugene, Oregon, and enjoys downhill skiing 



David L SmHti 

Plastic desrgn is the profes- 
Sronal interest of Dave 
Smiih, a mechanical en- 
gineer who pned HP's 
Corvallis Di\/ision in 1982 
He received a BS degree in 
mechanical engineering 
that same year from the 
California Polytechnic Siate 
University at San Luis 
Obispo. Dave did mechanical design and cal- 
culator R^D for Ihe HP 4eSX scientific calculator, 
and also worked on the HP 71 B. 1 BC. and 94 cal- 
culators and the HP B2240A thermal printer Bom 
in Klamath Falls. Oregon, Dave Ifves in Corvallis, 
ismarr-ed, and has a son. He enjoys woodworking. 
skKng, soft bail, and volleyball. 



Thomas B, Lindberg 

Tom Lindberg was an R&D 
and production engineer 
for the HP 48SX scientif C 
calculator. He also was a 
project en gf nee r during de- 
^/Glopment of the HP 7 IB, 
1BG, 2BC. 19B, and2eS 
1^ calculators. Tom joined 
. ^^ , I HP's Corvallis Division in 
m\ l ''' I, 1981 shortly after receiv- 
ing his BS degree in mechanical engineering and 
materials science from the University of Calrfornta 
at Dav is H e i s a reg i stered profess ion at en g i n eer 
Bom in RoyaE Oak. Michigan, he lives in Corvaliis, 
Oregon, and enjoys electronic mussc composition 





M. Jack Muranami 




mechaftical engineer 



Jack l\^uranami designed 
the memory card, memory 
card connector and bat- 
tery contacts for the 
HP 48SX sc;entiftc cal- 
culator. He pined HP's Cor- 
vallis Division shortSy after 
graduating from Rice Uni- 
versity in Houston. Texas, 
in 1 9a5 with a BS deg ree in 
ng Jack also heJped develop 



the HP B22AQA printer s^nd the HP 82242 A I R mod- 
ule lor the HP 4TC calculator. Bom m Tokyo, Japan, 
he lives m Corvallis. Oregon, is married, and has 
two children. Jack enjoys readjng, cooking, gar- 
dening, traveling, and buying toys for his children 
during business trips to Japan, 



35 -^ HP 48SX to System ; 




Steven L. Harper 

Steve Harper was respon- 
sible for the design of the 
memory cards, display, 
and I/O circuilry for the 
HP 48SX scientific cal- 
culator He has atso worked 
on the HP 9551 D instru- 
r-ient calibration system, 
Ihe HP 01 calculator/ watch, 
and the HP- IL system and 
devices. Steve jomed HP's Automatic Measure- 
ment Division tn 1 972, shortly atter graduating from 
Brigham Young University WJth BS and MSEE de- 
grees, The coauthor of a book on J he HP- 1 L system, 
Steve IS named as an inventor in an HP-IL protocol 
patent. Born in Med lord, Oregon, he lives m Cor- 
vallfs, /s married, has five children, and enjoys 
amateur radto, windsurfing, and stnging in the 
church choir. 



Robert S. Worsley 

^^^^^ Res ponsi ble for I/O p r i nting 

^^^^^^^^ and firmware for the 
^H^^^^ HP 48SX calculator. Bob 
W J^^B Worsley joined HP's Cor- 

^^\ ^^^^^ vallis Division in T977 He 
also helped develop firm- 
'.vai^e for the HP 41 and 
I P 423 calculators. He 
received a BSEE degree in 
1977 Ironn San Jose State 
Un'versiSy and an MSEE degree in 1982 from Ore- 
gon State University. A resident of Corvallis. Ore- 
gon, Bob enjoys hiking, and cross-country skiing. 



^, 



40 ~ HP 4asx Manufaetyfing : 



Richard W. Rlpef 

Machfne design and com- 
puter-controlled assembty 
machines are the major 

professional interests ol 
Rick Riper, a manufactur- 
ing engineer who foined 
HP's Corvallis Division in 
1982. He graduated from 
a "''^^^^^ Oregon State Untversity 

ri X^t^m ' -fl^^B that year with a BS degree 
in mechanical engineering. Rick coordinated the 
manufacturing engineering and fina' assembly of 
the HP 4SSX calculators He also has worked on 
t h e H P 1 Sene s and HP 1 8C/2BC families of c al ■ 
culators. A registered professional engineer in Ore- 
gon, he was bom in Chester. Pennsylvania, lives' 
in Corvaths. Oregon, is married, and is active as a 
Cut) Scout den leader He enjoys wood work«ng and 
photography 
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44 ZI ^tf^ 356SA Spectnim Analynr : 




Enc WjcWLfnd was ihe 
hajdware project mans ^- 
f Of ttie HP 3&SSA spect/ j : 
an^yzer He also heJped 

fJevsfop t^e vcHtTTTsieF lor 
the HP 349 7 A data acq lh s:- 
1 00 and conr/oi Mnit. the HP 
: 326A two-cfiannsl syfittis- 
i.zer. anci ihe HP 3561 A 
and HP 3662A dynamc 
sJgnsJ ariaiyzers He is rtamed an inventor on a pat- 
ent pending on IF calibration for the HP 3588 A 
spectrum analyzer Errc received a BSEE degree 
in 1 977 from the University of Washington, and then 
pined HP's Lake Stevens Instrument Division rhat 
same year He sen/es as a member of the SeattEe 
Pactfjc University Elecifical Engrneering Advisory 
Council Born in Seattle, he lives m Snohomish. 
Washington, is married, and has three children 
He enjoys amateur radio, woodworking, and 
astronomy 



R&D engcneer Joe Taran- 
!' no contributed lo ihe de- 
sign of the input and If cir- 
cuits and portions of the 
local osciifaior for the 
HP 3588A spectrum ana- 
lyzer. He also is a co- 
de ve lope r of the tocal osci I - 
iatorand reference circuitry 
Ifi "^ for the HP 3577 A network 
analyzer. Joe earned a SSEE degree (1979) and 
an MSEE degree [19fl1 ) from Purdue University, 
and joined HP s Lake Stevens Instrurneni Division 
in 1931 He is named an inventor on two patents 
pending for IF calibration for Ehe HP 35S8A spec- 
trum analyzer and the gated sweep capability m 
the HP 35858 spectrum analyzer Born in Mil- 
waukee, Wisconsin, he lives m Seattle, 
Washinglon. He enjoys hiking, bicycling, soccer, 
and archaeology. 



James H. Cauthom 

f ^^^^ mm Jim Cauthom jomed HP's 
■^^^^^ ^^ LaKe Sieverra Instrument 
DlyssJon as a customer sup- 
port engineer after he re- 
ceived his BSEE degree 
from Ihe Universily of 
Arizona in 1984. Afte r mov- 
ing to (he R&D lab ini 986, 
he began developing 
firmware systems for signai 
analyzer products including Ihe HP 3588A H<s 
professional interests include analog and digiial 
signal processing, cornmunications and reaMime 
firmware system design Before foming HP. ha 
worked as a co-op siudenf on raad-chanriel elec- 
tronics for an IBM magnate tape data siorage di- 
vision Born In New Orleans and raised Fn Arizona 
he Ijves in Everett, Washington Jim enjoys leisure 
time With his two sons, dancing, guitar music. 
movies, books, and hiking. 






Production engineer 
Kirsten Caft«3fi performed 
automated testing of the 
HP 33eBA spectrum 
analyzer S^ie jOnried HP s 
Lake Stevens Instrument 
Division ]ry ^B82. a month 
after she tece+ved a SSEE 
decree m 1981 from tt>e 
University of Washington 
Sirce then she has worked in hardware and sott- 
ware devefopment product investigations, soft- 
ware quality and production engineering for 
numerous HP producis. As a production errgineer , 
She was responsible for HP 3325A/B synihesizer 
fur>ction generators, HP 3335A and HP 3336A B. C 
synthesizer/fevei generators, and the HP 3312A 
function generator Bom jn Vancouver, Washing- 
ton. Kirs ten lives m Snohomish and has two sons, 
one of whom she adopied from an orphanage in 
Cinipulung, Romania She enjoys her vacation 
home at the beach, readingv walking, btking, and 
church activities. 



Jay M. Wardle 

■ Digital and analog signal 
processing are the profes- 
sional interests of Jay War- 
die, a design engineer who 
joined HP's Lake Stevens 
mstrument Division in 1984 
He designed Ihe digital IF, 
joded math coprocessor, 
I and diagnoslic software for 
the HP 3588 A spectrum 
anaiyzef Before [hat. he designed cd processor 
and diagnost-c software for the HP 35660 A 
dynamic signal analyzer Before joining HP, Jay 
pedormed hardware desEgn tor John Fluke Man- 
ufacturing Company s,nd Advanced Technology 
Labs He earned a BSEE degree in 1978 from 
Washington Slate Unrversityandan IVISEE degree 
in 1980 from the University Of Washsngion. Raised 
in Yakima, Washington, Jay lives inSeattle. is mar- 
ried, and has EWQ daughters He spends most of 
his leisure lime with his young chjJdren, and also 
enjoys hiking, climbing, and spelunking 



Timothy L. Hlllstrom 

After joining HPs Lake Ste- 
vens Instrumeni Division in 
1982. Tim Hillsirom de- 
signed and developed fre- 
quency reference cali- 
brator, and trigger circuits 
for the HP 3588A spectrum 
I analy/er. HfS rriapf profes- 
I s ion al in teres! s include os- 
cillators, frequency synthe- 
sizers, and phase noise. He is named an inventor 
on one paten! and on another patent pending on 
spectrum analyzer measurement features and cir- 
cuits ^^mal50lstheauTho^ of magazmeandcon- 
terence articles on oscillator theory and design. He 
earned a BSEE degree m 1 982 at the Un-versily ot 
Portland and an MSEE degree m 1 986 in analog/RF 
design from the University of Washington. Tim and 
his wife recently returned from a successful nine- 





week purr tey to Rocnan?a tinnging taaci^ two ciiif- 
dr^n ^iopted from orph^'iages in Arad ar^ 
Timisoara A tennis f^^calic who was txyn m Holty- 
wood Caiffornta, Tim livfes with hfs family in Everett, 
Washirtgton 



Roy L. Hasan 

V fecejver tF t»ftef , 
^rce. and receiver tnpui 
^.ge filter of the HP 358aA 
L -Ctrum arialyzer were 
]^ .eloped by Roy Mason. 
.A '; 984 g raduate of t he Un t- 
I versity of Nebraska at Lin- 
coln with a BSEE degree, 
he joined HP s Lake Ste- 
vens In sir lament Division 
that same year. He -s now working toward an MSEE 
degree Roy was in the US. Air Force from 1976 
to 1980 and a member of the Alt National Guard 
from 1 980 to 1 984 Born m Omaha. Nebraska, he 
lives in Lake Stevens. Washington, is marned. has 
two children, and enjoys woodworking and 
machine metal working (the latter a^ a result ot his 
work With high-frequency filters). 




S5 ^HP GIftrvcePlus : 




Rex Backman 

Rex Backman is a software 
engineer in the perfor- 
mance technology center 
at HP's Application £■ ropod 
Division He worked oi i the 
development of the HP 
GiancePlus,''XL diagnostic 
perlormance tool. In the 
past. Rex worked on MPE 
XL operating sy^^tem tesh 
mg and the development of oiher performance 
products such as GlancePlusA/ and CAPLAN/XL 
Rex joined HP in 1 982. shortly after receiving a BS 
degree in computer science from California State 
University at Chico He authored an article on per- 
formance management for Inieract magazine, and 
several conference papers presented at fnferex. 
His professional interests include user interfaces 
and ease-of-use features. Born in Redwood Cily, 
California, Rex lives in Citrus Heights and enjoys 
skiing, travef. and southwestern ad 



71 _^ Froducl Oevelopmenl Process : 



Douglaa Daetz 

I IHi^^^ Quality management 

I I^^IV^^ methods and the social im- 
g V^l plications of technology are 

■ VH the professional interests of 

JJSf C^ TB Dnug Daetz. who joined HP 
[ ^ ^ i^M Laboratories m 1985. He 
I if was an early participant in 

"H 'fi*^ "design for manufac- 
lurability ■ and "factory 
modeling" projects in HP 
Laboratories manutactunng research center. Now 
a quality engineer in HP's Corporate Quality De- 
partment, Doug has been promoting the use of 
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qualily function deploy m snt (QfO) m product and 
service development. Betofs pining HP, Doug was 
the directof of quality at Shugart Corporation and 
an assistant professor of industrial engineering at 
Stanford Univer^ily He earned a BE degree in 1 962 
in electrical engineering at yale University, an 
MSEE degree m 1 963 and a PhD degree in electri- 
cal enQin earing and computer science in 1968 
from the University of Cafifornia at Berkeley. He is 
a rr^ember of the IEEE. Ihe ArtTencan Society for 
Quality ControL the Society of Manufacturing En- 
gineers, and the American Society for Engineering 
Education. He is the aullior of articles on design for 
manufacturability and quality and quaNty function 
deployment, and originator of the multi variable dis- 
play technique now called the radar chart. Born in 
Prow'id ence, Rhode Island. Doug lives in Sun- 
nyvale, California, is married, has three sons, and 
enjoys stamp collecting, poetry, and life drawing 




\ P. Carmichael 

^^^. Bill Carmichaers profes- 

Jw^^^^k. sionai interests include de- 

'Mf mt, vefoping and applying 

^[Li^^Wh robust statistical tech- 
M^^ ^^ |l mques to real -wo rid prob- 
'*^^ lems. To aocompiish this, 

he earned an ABdegree m 
mathematjcs and statistjos 
in 1973. and a PlnD degree 
k in statistics at the University 
of Cahforriia at Berkeiey in 19&0. He joined HP's 
Stanford Park Division in 1 932 as a statistician and 
implemented a totat quality control (TQC) program. 
As a productivity manager., he implemented con- 
tinuous process imp rove men t techniques m R&D 
at HP's Stanford ParK Division, and developed 
break even time f BET) software at HP's Corporate 
Engrneehng. Before joining HP, he was an assistant 
professor of stalisticsatthe University of Wisconsin 
in Madison. Born in Red Bluff. California, he lives 
in San Francisco and enjoys hiking , biking , and re- 
storing Victorian-era edifices. 



Edith Wflson 

As HPs manager of prod- 
uct definition and corporate 
I manufacturing in Europe, 
Edith Wilson wears three 
hats She IS responsible lor 
HP's product detimt^on pro- 
cess, the worldwide bench- 
marking of product defini- 
tion, and starting HP's 
product generation ef fori in 
Eu?'ope. previously. Edith served as section man- 
ager for HP product definition at Corporate En- 
gineer-ng. Aftef joining HP Laboratories in 1960 as 
amechanrcal engineer, she worked on ttie electron 
beam machine project, designing portions Of the 
wafer-stage mechanism. She then joined iheOpto- 
eSectronics Divtsion and developed a tape-and- 
reei LED process. As a project manager, she de- 
signed and developed HP's ASCII-addressable 
5x 7 dot matnx LED display family. As a section 
manager, she helped devebp custom LED dis- 
piays, print heads, and LED aulotaral^e lights Be- 
forejorning HP, Edith was a mechanicat engineer 




with Tetesensory Systems, Inc.. working on a hand 
scanner for the Optacon tactile imaging reader tor 
btsnd people. She earned a BSE degree m biomed- 
rcai engineer rng in 19 77 from Duke University, an 
MS degree in mechanical engineering m 1 979 from 
Stanford University, and an Engineer's Degree in 
mechanical er>gineering at Stanford University m 
1 990. The author of arlicies on data analysis, TQC, 
and product definition at HP, Edith's major profes^ 
Sional interests include project management and 
design innovation, She is active in community proj- 
ects, including the opening of the S'licon Valley 
Technology Museum Born m New Haven, Connec- 
tECUt. Edith was recently married, and now lives m 
London, England She is currently remodeling a 
historically registered house, and she erijoys sports 
and gardening. 



Spertcer B. Graves 

Spencer Graves ioined 
HP's Santa Clara Division m 
1982 as a statistician In 
1 984 he transferred to the 
Computer Supplies Opera- 
tion {now the Direct Market- 
ing Division] wtiere he 
served as a statistician and 
quality services manager 
~W for TQC planning, course 

development, and training, and developed the pro- 
totype for the HP TQC course. Spencer joined HP 
from the University of Wisconsin at Madison, where 
he received a PhD degree { 1 983) in statistics, He 
earned a BS degree (1967} in aerospace engineer- 
ing at the University of Colorado In Boulder, an MS 
degree (1972) m industnal engineering at the Uni- 
versity of Pittsburgh, and an MA degree (1 975) in 
mat hematics at the University ot Missouri in Kansas 
City. Before joining HP, Spencer was an operations 
analyst at the MidwestPesearch Institute In Kansas 
City, an indusinat erigmeer and office manager in 
the U.S. Air Force, and a volunteer teacher in Latin 
America Spencer is now a consultant and is teach- 
ing Industnaf Systems Engineenng at San Jose 
State University. His specialties include improving 
Strategic management and the product develop- 
ment process. He is a member of the American So- 
ciety for Quality Control, the American Statistical 
Association, the Institute of Management Sciences. 
and the American Economics Association. He has 
published papers on sirategic management and 
the applicatfon of rm prove me nt concepts to na- 
tionaJ and international problems. Born in Oberhn. 
Kansas, ha lives in San Jose, California, is married 
and has a stepdaughter. 





David Lubl<in was the proi- 
ect leader for DSEE hetero- 
geneous configuration 
management at HP's 
Apollo Systems Division lor 
the last three years. Before 
joining Apollo, he worked 
on terabyte archival stor- 
age and supercomputer 
operating systems at Law- 



rence Uvermore NationaE Laboratory for five years, 
He received a BA degree ( 1 978) in tinguistlcs from 
the State University ol New York at Stony Brool< and 
an MS degree (1982) m computer science from 
Michigan Slate University, where he also did a year 
of doctoral work in artificial intetligence. He is a 
member ol the Science Fiction Writers of America 
David was born in New York but spent five years 
living in Israel ^ where he sampled the Yomi Kippur 
War) He now lives m Nashua. New Hampshire, is 
married, and has a daughter The eldest of 13 chil- 
dren, he IS learning to tly 



&4 ^ Paraltet Development via RCS ' 




John W. Goodrraw 

Computer and system ar- 
chitecture, operating sys- 
tems, and image process- 
ing are the professional in- 
terests of John Goodnow, 
a proiecl manager at HP's 
Imaging Systems Division. 
In 1983, he joined HFs 
Andover Division, now the 
y Imaging Systems Division, 
shortly after receiving a BS degree m electrical en- 
grneehng from the University of Pennsylvania. He 
earned an MS degree in electrical engineering in 
1980 from Stanford University through the Honors 
Coop program. After Joining HP, he wort<ed on HP 
PaoeWriter electrocardiographs and ultrasound 
system software as a development engineer John 
(•s now a project manager worthing on ultrasound 
software development. Born in Ygrk, Pennsylvania, 
he lives in Andover, Massachusetts, is married, 
and enjoys windsurfing, skiing, woodworking, 
and vacationing on Marthas Vineyard. 



90^^'^tegrste<l Project Support ', 




Ronald F. Richardson 

Ron Hichardson began his 

naree' as a programmer 
r3'"^a-ys' when tie pined 
HP's Corporate Parts 
Center sn 1 979. As a quality 
process engjneer in HP's 
Poseville Networks Divi- 
"^lon , he was the lead for the 
team developing the tech- 
nical computing environ- 
ment for cooperative computing. In the past, he has 
worked as an R&D software development engineer 
and a program manager at other HP divisions. He 
IS now a process consultant worthing to enhance 
hardware and software productivity with new de- 
sign tools and methods He will receive a BS de- 
gree in computer science from Cafifornja State Uni- 
versity at Chico this year and is concurrently regis- 
tered m an MSCS program there. Bom in San^a 
Cruz. California, he lives m Rocktm, is marned, and 
has three children. He enpys miotorcycling, hunt- 
ing, fishing, hiktng, and camping with his famiEy. 
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Easy-to-Use Peformance Tools with 
a Consistent User Interface Across 
HP Operating Systems 

By involving customers in the product development 
process and incorporating their feedback into tfie product, 
HP GlancePlus has eliminated the mystique commonly 
associated with performance tools. Exception-based 
reporting displays only the interesting data^ 

by Rex A. Backman 



ALL HP COMPUTER SYSTEM users should be able 
to use and understand their performance tools. This 
concept was the guiding principle behind the ¥iP 
GlancePlus family of diagnostic performance tools created 
by the performance technology' cenler of HP's Application 
Support Division. Typically, computer system [jerform- 
ance tools have been directed towards the teclmically 
advanced user. The focus on tools that required a high 
degree of operating system knowledge iefl out novice ustirn. 
Feedback from our cuslomers regard hig computer system 
diagnostic performance tools subtly addressed this issue 
by requesting performance tools that were consistent in 
look and feel across platforms (MPE V, MPE XL. and HP-UX 
operating systems), were easy tu use. and were low in cost. 
To answer these customer needs, ihe HP GlancePlus family 
of diagnostic p erf or mane; e tools wa^s created. 

Performance diagnostic tools provide the tnistomer with 
a means of seeing and understanding the current status of 
the machine at any time. These tools are typit:ally used to 
diagnose machines when an abnormal situation is present. 
Abnormal situations can be a variety of events ranging from 
poor terminal response time for a specific end user to over- 
all sluggishness in the machine. Whatever the symptom, 
the customer has deemed something to be out of the ordi- 
nary and the performance tool is executed to display real- 
time data about the machine so that appropriate action can 
be taken to correct the situation. HP GlancePlus Is typically 
used to determine information suf:h as who is the main 
GPU consumer, where are the record pointers within a file, 
who is accessing a certain file, or what disk drive is most 
heavily used. All of these actions are typical of the diagnos- 
tic quadrant of performance management, and keep the 
user abreast of the current status of the machine. The per- 
formance management quadrant and other types of perfor- 
mance tools are described on page 70. 

Background 

Hisluritally* many HP [lerformance tools have started as 
software laboratory prototypes or special tools. These 
software prototypes were usually trying to address a spe- 
cific and innnedjBte need in a project -development cycle. 



For example, new operating systems development w^ork 
neeessitated some form of a mrniitor to track modifications 
made in system level algorithms. Upon completion of the 
project-development cycle, the performance tools would, 
sometimes evolve into a salable customer product. Unfor- 
tunatcly^ these customer performant:e tools still retained 
the roughness associated with laboratory prototypes. While 
some effort was spent on improving the prototypes, this 
work usually contumtrated on an improved user interface 
with no true thought given to the perlortnance data that 
was displayed. The result of this quick transformation from 
development tool to customer product was a utility that 
provided too much data, provided data that was not appli- 
cable to the customer's neetls. and was too expensive. As 
a result, performance management on our customer s ma- 
chines was often relegated to technical experts. This caused 
an aura of mystique about the perforniance discipline 
because the thinking was that if you had to be an expert 
to use a tool, then ihe discipline must truly be difficult. 

Removing the IWystfque 

The engineecs at the performance technology cenler rec- 
ognized, like many others, that performance management 
was not difficnlt nor should Hewlett-Packard customers 
find it so. Several goals were identified at the start of the 
product cycle to ensure that the mystique about perfor- 
mance management was eliminated. An aggressive devel- 
opment schedule, coupled with frequent and repeated cus- 
tomer feedbarik sessions, was part of the development 
methodology used to keep the product team focused on 
the goal of creating a useful, more informative performance 
tool lor our customers. Customer feedback was the essential 
checkpoint vehicle used to ensure that the tool was provid- 
ing valuable and pertinent data (see "Design Prototyping 
for HP GlancePlus" on page 69). 

This customer feedback loop was important because the 
HP Glani:ePlus family is based on a different t>T3e of model 
than previous tools. To help remove the mystique of per* 
formance tools. HP GlancePlus incorporates a method 
of exception-based performance reporting. This approach 
allows tool designers to limit the data displayed to only 
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! few metrics tfiat are considered interest ingn This txm- 
C^i aljows the and user to be concerned only with ihe 
interesting e%^Bnt;s on the machine. By focusing only on 
these interesting events^ f?nd users can ascertain what is 
wrong much faster. 

In our diagnostic tools, Information can be divided into 
various hierarchies such as global CPU use* global I/U activ- 
ity, global memory allocation, and process-specific use. 
The first three of these hierarchies lire t:ondensed into 
single screens to provide information lo I he tool user. The 
process hierarchy presents a challenge because of the pos- 
sible volume of data. To lower this volume, the exception- 
based methodology provides only information on processes 
that have some kind of activity during a specified time 
interval. Examples of activity for a process include CPU 
time consumption* disk reads or writes ^ and terminal trans- 
actions. Processes that have engaged in any of these 
activities during the specified time interval are considered 
exceptions and are classified as interesting- A process that 
does not have any activity is of no interest and therefore 
is not reported. 

Additional benefits from the exception -based report hig 
method are that HP GlancePlus customers are not over- 
vvhehned with useless data. The data that is display t^d lias 
direct impact on their ability to identify and understand 
the current performance problem. Exception -based report- 
ing and nplional color graphic displays result in a tool that 
is much mtjre ccncise and informative than previous eHorts. 
This change in data representation is the key to making 
HP GlancePlus performant:e [ools easier to use across all 
levels of technical expertise. 

As previously mentioned, earlier generations of perfor- 
mance tools provided too much in-depth reporting on sys- 
tem metrics. Many of these metrics w^ere found hidden 
deep within the operating system kernel and were of no 
relevance to the typical end user. These additional metrics 
also made the situation worse by requiring unnecessary 
display screens, causing confusion w'hen moving from 
screen to screen. One of the design goals for HP GlancePlus 
was to eliminate this problem. With the exception-based 
method of reporting, fewer display screens are used to dis- 



play only valuable and pertinent metritis for performance 
diagnosis. Positive customer feedback to this approach w^as 
received almost immediately. Sites involved in the design 
prototyping phase almost always reported that less techni- 
cally adepi end tisers were finding the tools easy to use 
and understand. Most important, end users reporteti that 
the tools were providing a service. Time and effort lo iden- 
tify performance problems were lowered, and many sites 
repeatedly stated that through the use of the new tools they 
had easily i den tilled pe r fo r ma nt:e problems and were able 
to take the appropriate action with much less anxiety than 
before. 

Versions and Algorithms 

Three versions exist in the HP GlancePlus family, one 
for eHt:h specific operaling system platform. Represented 
platforms are I he MPE V, MPE XL and HP-UX operating 
systems [including I he workstation and HP 9000 Series 
800 versions]. The HP GlancePlus version for each environ- 
ment or platform had identical design goals and each envi- 
ronment uses similar algorithms t:o retrieve the required 
performance metrics. 

Differences in low -level hardware and software struc- 
tures require each model to depend on different sources 
of data to feed the performance algorithms. These core 
differences are handled independently by each specific 
modeh However, a common and similar user interface 
guarantees that customers have a consistent perspective of 
their perlormance metrics [see Figs, l, 2, and 3). This t:on- 
sistent user interface across the HP platforms was viewed 
as way to bring a level of comfort to end users. 

Previous tools did not offer any degree of consistency, 
and this added to the mystique that we were trying to 
remove. The comfort level was low in shops that w^ere 
running in mixed modes. Data centers that included more 
I ban one operating system plaiform, such as MPE V and 
MPE XL, provided performance tools with different u,ser 
interfaces. By con Iras I I he user interface consistency 
offered by HP GlancePlus allows these users to switch from 
machine to machine with ease. 

Performance algorithms are used by the HP GlancePlus 
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Fig, 2. This screen shows the de- 
iautt gfotyai screen for HP G/ance- 
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taoJs to compute metrics for each specified time interval. 
The differences ixi software structures across the platforms 
mentioned above require different access methods to 
acquire llie data. Once acquired ^ the algorithms are basic 
ones such as deriving the rate per minute of terminal trans- 
actions, disk use percent, and CPU use percent. 

The HP GlanccPlus tools are designed to be used interac- 
tively, or in a real-time mode, with the performance metrics 
displayed as rates, absolute values, or percentages. To 
derive these values two time points are required. The dif- 
ference between the time points is referred to as the inter- 
vaL and is used as the base for all metrics the user sees. 
The interval can be as small as five seconds or as large as 
several minutes. Usually ^ end users configure the inten^al 
between thirty and sixty seconds* As each interval expires, 
another time point is met, data points are collected, and 
performance metrics are computed. This refreshing of the 
performance metrics gives the ond user a continuous per- 
spective of what is happening on the machine. Examples 
of these metrics include system disk rates» which state the 
number of physical disk t/Os per second, main memory 



use. which states how much of main memory is being used 
Ln megabytes, and global CPU use, which shows the per- 
centage of overall use of the CPU in the most current 
interval. 

Data Sources 

DatH sources for the HP GlaiicePius family differ from 
platform to platform (see Fig. 4}. The underlying differences 
in the data sources are hidden from customers. However, 
these separate and unique data sources arc the main con- 
tributors to the HP GlancePtus performance tools. Each 
platform has a subsystem associated with the base operat- 
ing system called the measurement interface. Each mea- 
surement interface, regardless of its platform. Is composed 
of two elements: instrumentation and counters. The 
instrumentation interface is where certain events within 
the operating systems are recorded. This is accomplished 
by adding code to specific modules of the operating system 
kernel that record the activities that tbe specified modules 
perform. The added code consists of high-performance 
statements that simply update the proper counters reflect- 



HP 11791A GlancePIus/UX A.BB.BB 12^25-53 hp*Jail 900B^3ba Current Aug Hlih 



CPU Utll 5 

Disk Util F 

Mewjry Util S 

Suop Util f 



Dei^icB 



^dev/dsk/lsB 
^deu/dsk>'Zs0 
/dey/dsk^3sB 



GUbal 



CPU 



SU 



FUU 



SU 



FO 



u 


38X 


51>^ 


^3y. 




3T/: 


BX 


7hy. 




ray. 


hhy. 


rax 


D 


^TA 


BTA 


97X 



DISK queue: lengths 



Cdrrent 



q=0 



a(ct< 



Z< q< =4 



4< q< =B 



qVB 



1,7 
l.B 

i.e 
13. a 



29/ 

9 ay. 

TT/- 
91Z 



MeHory 



DlEk 



sr/: 

3X 



4^ 

a/. 
BX 



47 


BX 


ax 


ex 


ax 


BX 


ax 


BX 







Page 


I nf I 


Next 


Sel Bct 


Help 


E>cit 


Keys 


Process 




Glance 



Fig. 3. This is an HP GlancePlasf 
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Fig. 4. Data sources for HP GiancePfus, 

ing th.(3 action tJiat has taken place. For example^ the com- 
pletion of a disk read is marked in the disk driver code. 
Counters are nothing more than accumulators for certain 
types of operating system events. Counters can he viewed 
as time stamps signify^ing the amount of time an event has 
taken. 

Fig. B shows the logical map of the MPE XL measurement 
interface data slructure. This structure shows I he counlers 
used hy the HP CI ancePl us/XL tool While this structure 
is unique to the MPE XL operating system, it is conimon 
for measurement interface structures to organize data in a 
hierarchy of classes of global, process, and I/O events. In 
the case of the MPE XL operating system, the counters are 
organised into these three classes a1 the highest leveL The 



subclass level represents an intermediate level of organiza- 
tion that provides the ability to identify objects of a similar 
type. For example, a subclass in the I/O class identifies 
each logical device present on the machine. Subclasses da 
not exist in the global class, but they do exist in the process 
class to identify each process* Each suhclass is made up 
of groups of counters* The counters in each group are log- 
ically related by function. An example would be the file 
system counters for a process. This group of counters con- 
tains ail the counters associated with file system activities 
for a specific process. To access a counter , the program 
must access the proper class (global, process, or 1/0) , select 
the proper subclass if applicable, and then access the group 
that contains the specific counter of interest. 

While each operating system has a measurement inter- 
face, the sets of counters differ. This difference presented a 
challenge fortheHPGlancePlus development team because 
we had to develop the appropriate measurement interface 
for each platform and stilt present to the end user similar 
metrics regardless of the platform. The challenge was over- 
come by mapping the disparate measurement interface 
counters to a common set of performance metrics that all 
juodels shared. While some metrics are unique to each 
platform, these are in the minority. The majority of the 
metrics did map to common data items for each version of 
HP GlancePlus. 

Another source of data is non performance-related items 
residing in certain operating system structures such as pro- 
cess-specific information not contained in the pla I form's 
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Design Prototyping for HP GlancePlus 



Design prototypmg is Ihe process oJ placing e very earfy prod- 
uct pratofype in ihe hands oi a select number of prospective 
CliSlomers and alJowing tnem to hefp design the produci, lest 
the functionality, and refine the product in production envirorh 
ments This process require thai there be a continuous dialog 
with Ihe selected cuslomefs arKJ a quick response to their 
requests wittiin days 

For HP GlancePlys we wanted this set of costorriers to give 
us a good representation of our target market. The eigtit custom- 
ers selected ranged from naive to sophlsttcated, from single-per- 
son shops to large data processing shops and from sites with 
only HP MPE V or HP MPE XL operating systems to sites with 
both operating systems. The overriding requirement was that the 
customers had a need to use the product 

One week after sending the prototype programs, we called 
each customer to (Jnd out how they had used the prototype and 
how it could be improved. Interviews were conducted directly 
with the customers so that we could completely understand what 
they needed. Anything that two or more of the customers 
suggested was implemented for the next prolotype version Opin- 
ions from the development team that disagreed with customer 
consensus were discarded since we were not developing a prod- 
uct to sell to ourselves We then made the changes, transmitted 
them electronically to our prototype customers, and began the 
cycle again 

Four repetitions of this cycle were achieved within six weeks. 



When customers saw changes they had requested implemented 
within days, ttieir general read ion was disbelief. Disbelief turned 
to high enifiusSasm in providing feedback as they realized their 
ideas were not only be^ng heard but acted upon immediately. 
This fT>^hodology allowed cofrection of a lot of trntations that 
often spur customers to ask "Didnt anyone use this produci 
before it was released?' It also albwed me addition of needed 
functionality that nofmaily is not recognized and added until cus- 
tomers submit enhancement requests And rr^ost important, it 
created a user interface shaped by users. 

Some valuable lessons were learned from design prototyping 
Firs! of all, we discovered that when users have access to 
updated versions of a piece ot software rapidly they can easily 
decide on their real needs. For example, users may have their 
specifications met exactly and then find out that it only helps 
them to understand what they really need We also learned that 
prototypmg can be done with third-generation programming lan- 
guages. Finally, we learned that design prototyping can give a 
produci the feel of a second- or third-release produci at introduc- 
tion. The benefit to tX3th customer and devetopmeni group are 
great in overall cost reduction and product usability 

Joe Thomas 

Development Engineer 

Performance Technology Center/ 

Applicalion Support Division 



measurement interface. Examples include proces*^ wait 
reasons, current process priority, and file system informa- 
tion related to the process. This information is used to 
provide discrete data on process or program related items. 
While not part of the measurement interlace, these data 
items provide important information that can be used to 
ai d in perf or in a n n e man agem en t . M at u ri ty o f th e p I a t f o rni s 
dictated how this data was to he retrieved; MFE provides 
direct routines while HP-UX data is retrieved using a pro- 
prietary hbrary of routines. These secondary data sources 
coupled with the platform-specific measurement interfaces 
provide each HP GlancePlus model with all required data 
items for computing perlnrmance metrics. 

Binding the measurement interface as ihe primary data 
source with the secondary kernel data structures provides 
B nSimple and streamlined approach to the data gathering 
required for performance metrics. Tying these data struc- 
tures with relatively straightforward aiming algorithms 
allowed the design team to meet the goai of creating easy-to- 



use performance diagnostic fools. 

Processing Logic 

A look at the internal logic of the HP GlancePlus pro- 
grams shows a simple and efficient design. By having a 
core technology avaiiahle. each model was able to leverage 
code from previously written softivare modules. The core 
section is an area of software procedures and programs that 
existed for other HP software engineering tools or products. 
The functionality provided by these tools is used to collect 
data from the measurement interface and kernel data struc- 
tures for system wide global and process-specilir: perfor- 
mance metrics. Some of the software modules that were 
reused hacl been written for the HP LaserRX family of per- 
formance products^ and with very slight modifications they 
fit into the HP GlancePlus product easily. 

Performance data at the global level includes system- 
wide information that can provide some insight Into system- 
wide bottleneck conditions. Overall disk throughput, mem- 
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ory manager use, and global file open rates are examples of 
global metrics. Process-specif! c data includes data items that 
are associated with e specific process for the current intervaJ. 
This data provides a mechanism by which lo view a process 
in detail and compare il to the bigger picture of global 
performance data. As shown in Fig- fi, the modules respon- 
sible for collecting and sunrniariiicing global and process- 
specific data are in a refresh loop in which they are continu- 
ally sampling, processing, and sending the data to forrnat- 
ters for display. 

Conclusion 

Market acceptance of the HP GlancePlus family has been 
favorable. The paradigni that previously existed for perior- 
mance diagnostic tools was one of expensive products that 
were difficult to use and understand. This has now changed 
as Hewdott-Packard customers can use these new inexpen- 



sive and easy-to-use offerings. A successful first step has 
been taken to provide intuitive performance diagnostic 
tools, 
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The Performance Tool Quadrant 



Ttie HP pedormance technoiogy cenler 's development of per- 
formance tooJs is based on a core area surrounded by four 
distinct areas of performance management (see Ftg, 1). This 
approach differs from other perspectives on performance prod- 
ucts but allows HP to offer distinct offerings in each area, or 
quadrant, wfthoul sacrificing [he focus or effectiveness of the 
specified tool. 

The core area consists of common access routines thai provide 
access to performance metrics regardless of the operating sys- 
tem platform. The cornmorfality of data access provides a 
mechanism by which the separate tools from each of the quad- 
rants shown in Fig 1 can then access and manipulate data. 

Each performance quadrant defines a different area of tocu^ 
for performance management tooEs. 

Appticalicrn OptiiiiL:£ation. This quadrant provides the tools 
oecessary to Hne-lune application programs, By analyzing where 
a program has spent its time, the user of application optimisation 
tools may be able to identify flaws in togic which if corrected 
may result in more efficient code. 

Diagnostic Tools. Tools in this qoadrant provide the capability 
to see what is currently happening on the machine. The HP 
GlancePlus tooJs described in this article fit ihis crfterron. 
Resource Managem*?nt. This quadrant provides tools that allow 
users to gain a targer perspective of how the system has been 
used by tracking multiple criteria over periods of time ranging 
from a few hours to several months. These criteria are items such 
as global CPU use, disk i/0 use by disk drive, and process-spe- 
cific information 

Capcicily Planning. This quadrant provides tools that enable the 
performance planner to ask "what if questions. Using sophisti- 
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Fig, 1- Performance tool quadrants. 

cated analytic modeling techniques, end users can project their 
future computing needs. 

Using the core as a common technical focal point, each quad- 
rant addresses a specific need. From each quadrant comes an 
offering of products that address that specific performance man- 
agement need. The result is that Hewlett-Packard system users 
can pick and choose their performance toolset to fit Ihetr budget 
and functionaiity requirements. 

flex Bstckman 

Development Engineer 

Performance Technology Center 

Application Support Division 
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Improving the Product Development 
Process 

To define, design, and produce products and services that 
will be successful In the marketplace, its necessary to 
understand the product developnnent process and employ 
tools to measure and improve this process. 

by Spencer B. Graves, William P. Carmichael, Douglas Daetz, and Edith Wilson 



MANAGERS IN MARKETING, manufacturing, and 
especially research and development at HP are 
becoming more aware that they jointly manage a 
cross-functional process. Their people define and design 
a product and develop processes to manufacture and mar- 
ket that product (see Fig, 1). 

Many HP divisions are v^^orking to improve this process^ 
I'hcir improvement efforts rely on conc:epts such as break- 
even time [BET), post-introduction product reviews, in- 
process project retrospective reviews* and quality function 
deployment [QFDJ. This paper briefly describes these tech- 
niques. Improvemenl efforts in the R&D departments of 
ot h er or^n n i za t i on r? are d fiscrihed in references 1,2, and 3 . 

Break- Even Time 

Break-even time, or BET, has been identified v^rithin HP 
as a primary metric; for the development process. A simph^ 
definition of BET is that it is the time from the initiati<jn 
of a project to the point when all the design and startup 
costs have been recovered and the project is generating a 
net profit. Illustrative cal£:ulations nm presented in Fig. 2. 
BET is a reasonable mcrisure because it incbjdti.s market 
acceptance, cost of production and sales, selling price, lime 
value of money, and startup costs. Partial support for using 
a concept like BET in other compan[e.s [:an he found in 
references 4 anci 5, 

Measures such as break-even time may ultimately 
improve management's ability to predict prnfitabllity as 
early as initial product concept.* The data necessary to 
attempt tn improve fctrerasts of [jiijfihihility would he simi- 



lar to PIMS {Profit Impact of Marketing Strategy)/ The 
PI MS research program was initiated in 1972 for the spe- 
cific purpose of determining how key dimensions of strat- 
egy affect profitability and growth. Since that time. 450 
corporations have contributed data. PIMS data supports 
part of the famous Deming^ chain reaction: higher quality 
tends to improve market share, to enhance ability to charge 
a higher price, and to decrea.se costs, all of whicb contribute 
to higher profit. By combining BET data with the results 
of post- introduction product reviews [see belovvln managers 
should be able to identify things they need to do to build 
on previous experience (like PIMsl and Improve their abil- 
ity to forecast profitability, 

Breaic-even time Is only one measure, and is evaluated 
In combination with other measures such as the estimated 
net preseni value of a subproduct line under various future 
investment assumptions. BET alone could push managers 
to do the wrong thing in some cases bet;ause it t!oes not 
consider leverage or product success beyond the initial 
payback period. BET will not properly evaluate a product 
that is expected to open up a new markpt and whose ulti- 
mate success depends on whothtjr hit ore products are able 
to leverage that entry for higher profitability. BET also does 
not consider the cannibalism of a successhil product by a 
follow^-on. In some rases, the organization can protect mar- 
ket share by introducing a follow-on product early. In other 
cases the early introduction of a tbl low-on product may 

"McHugn'"' describCiS nov^ sorne engineers at HP's Roseviliie Ne{woi1<, Division have com- 
pared acriial with jnitlaJ estimatea of d6V6l(jipm&rit lima and have umproved ihmt abiiny lo 
fo/ecasl devefoprnent cfiats- by HE\ng thai informalJon 
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sugg^^l a misdirection ol R&D resources. No measure is 
perfect. For example. BET cannol be calculated if the proj- 
ect is canceled or if the product never recovers costs. To 
correct for this, some entities in HP compute a division- 
wide BET that includes canceled and unprofitable develop- 
ment efforts. Throughout HP, BET is being used to improve 
the R&D prrjcess within a division. Some of the possible 
causes of poor break -even time are summarized in Fig. 3, 
To complement ihe BET metric, tools are needed tor 
evaluating the strengths and weaJcnesses of the manage- 
ment of a project. Two such diagnostic tools that are 
intended to help evaluate and improve pro] eel management 
are post-introduction product revievi^s and in-process proj- 
ect retrospective reviews. 

Post-Introduction Product Reviews 

Kaoru Ishikawa* sakK 'Whenever I am asked to help 
introduce a total quality control program to a company. I 
choose for my case study one of the company's new product 
development projects that is full of problems." Ishikawa 
found thdt his dieuts learned a lot by studying their own 
experience in a structured way— and he provided the slruc- 
ture. The structure is essential to the learning. As Dealing^" 
explains: **Expertence without theory teaches nothing. In 
fact, experience cannot even be recorded unless there is 
some theory, however crude, that leads to a hypothesis 
and a system by which to catalog observations." 

Post'introduction product reviews and project retrospec- 
tive reviews are vehicles for developing and improving the 
tbi^jretical understanding that R^D managers use to guide 



Consumer Research 

not Used to 

Define Product 



Uncor^t rolled 
External Events 




Engineering Managerrtent 

Fig, 3, Possible causes of poor breakeven time. 



their work. A study of this nature is being conducted at 
HP's Corporate Engineering. Ten factors have been iden- 
tified that distinguish successful from unsuccessful proj- 
ects (i,e., projects that met their initially stated objectives 
and those that didn't). Fig. 4 lists these ten factors and 
shows a comparison of six successful and six unsuccessful 
projects. 

From Fig. 4 it is obvious that in unsuccessful projects 
many factors w^ere either omitted entirely or done 
inadequately. With information like thai given in Fig- 4. 
engineering project teams and their management can 
ensure that the 1 actors causing unsuccessful projects are 
addressed when creating a product definition. Of course 
this requires that a structure be in place that encourages 
early and complete consideration of these issues. Several 
success-versus-faiiurc studies have been conducted. For 
example, researchers at the University of Sussex'^ paired 
29 commercially successful innovations with an equal 
number of unsuccessful innovations. They identified five 
factors that distinguished successful from unsuccessful 
innovations: 
m Understanding user needs 

■ Marketing 

m Efficiency of ttie development effort 

■ Effective use of outside technology 

■ Project loaders wnth more .seniority and authority. 

By using any one of these five factors, they could identify 
the successful innovations in two-thirds of the pairs cor- 
rectly, and by ixsing the top three factors, they could classify 
all but two of the pairs correctly. Similar types of studies 
have been reported by other researchers. '"'^'*'^^''^^^ 

Among the projects summarized in Fig. 4, the most com- 
mon problem was misunderstanding user needs. Although 
the sample size is small, it suggests that some benefit could 
be gained from more effective use of consumer reseEirch, 
and from using a technique such as quality function deph^y- 
ment to help manage the results of consumer research, 
competitive analyses, and the subsequent detnsions. 

The major point here is not the relalive importance of 
the factors shown in Fig. 4. A siniliar study in another 
organization or at another time might identify- different 
issues as being more important to that organization at that 
time. Each organization is unique. Data such as that 
reported here can be used to help an organization's mem- 
bers improve the way they manage their business. The hard 
part is not in collecting the data but in knowing what to 
collect and in becoming convinced that it is really worlh- 
w^hile to regularly collect and use such data to make 
improvements. For this, top management support is criti- 
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cal. Experience with similar improvement efforts has estab- 
lished that people rarely have time for efforts like this 
without strong maiiagemBnt support. The data collection 
and anajysis is a minor expense when compared to the 
payback of bolstering the organization's performance in 
weak areas. 

One discouraging aspect of post-introduction product 
reviews is that the cycle typically takes years. It is difficult 
to maintain the discipline to collect the data required when 
the analysis will take place so far in the future. Several HP 
divisions deal with this long-cycle-time issue by conduct- 
ing similar evaluations at the end of each major phase in 
an R&D project. These are called in -pro cess project retro- 
spective reviews, or simply project retrospective reviews, 

In-Process Project Retrospective Reviews 

Experts discussing the management of product develop- 
ment have recommended reviews at various stages to help 
keej} the project on track. ^^'^ Some HP divisions use these 
reviews both to help keep projects on track and to improve 
the ways in which projects are managed. At one HP divi- 
sion, at the end of each major phase of an R&D project, 
each member of a cross-functional project team completes 
a new product development and introduction follow-up 
surv^ey. The participants are asked to desf^ribe what went 
well, what went poorly, and what they would like to see 
different In the future. A sample questionnaire is shown 
in Fig. 5, The results are tabulated and summarized and 
presented to the R&D management. Fig. 6 summarizes the 
findings from four different projects. 

This particular analysis was of great help to Liie R&D 
management. For example, the biggest problem in Fig, B. 
deficient project planning and scheduling, motivated the 
management to make better use of Its existing PERT (Pro- 
gram Evaluation and Review Technique) planning tools. 
PERT is a detailed project planning and scheduling tool 
Until this survey was conducted, the R&D managers had 
little to tell them whether they had made an adequate PERT 
chart— or even needed one. With feedback in the form of 
Fig. 6. R&D managers learned why they needed to use PERT 
and how to know if they had done it correctly. For example, 
they found that many problems aiose from misunderstand- 
ings in deciding when a task was completed. From this. 
R&D managers cone hided that tasks should be defined in 
terms of specific deliverables. LSimilarly, they found that 



they tended to have more problems with larger rather than 
smaller tasks. In looking at this, the R&D managers decided 
that tasks on a PERT chart that required SO hours or more 
should bo decomposed into smaller tasks with intermediate 



0) NAME (optional); 

1) FOE IT EON (during de ve 1 o pment/ itit roduet i on J : 

Engineer Supervisor J Wanager Other 

2) FUNCTIOtiAL AREA and DEPARTMENT (during development / 
introduction) : 

^ |l£t> MarJceting 

Manufacturing ^Quality Finance 

-}} Based on your ijivolveinent, please rate each of the 

following aspects of the product development/ 

introduction effort, on a scale of 1 to 5, where 

1_-,, 2 ^^^^3 ^-.—-4 5 

very poor poor acceptable good very good 

How well were you infonned of the overall 

development/ introduction plan and the role that 

you were expected to play in it? 
How much of an opportunity did you have to influence 

the portion of the dGveiopment/ introduction plan 

that related directly to your role and 

responsihilities? 
How well did you understand which deliverables you 

were responsible for, who the custopierE were for 

these deliverables, and what were their specific 

needs? 
How adequate was the araount of tijne allotted to you 

to complete your activities? 
How adequate was the quantity of resources allotted 

to you to complete your activities? 
During the course of the development/introduction. 

how well were you inforisiod of the status of other 

activities that could affect your ability to 

complete your own activities a a planned? 
How affectively were risks and potential obstacles 

identified and dealt: with over the course of the 

developtnent / introduction? 
HOW well was the development/ introduction effort 

coordinated and managed over time? 
Overall* how satisfying of an experience was your 

involvement in the devalopmont/introductiDn 

effort? 
How useful was a reference such as a new product 

development jnanual over the course of your 

i nvo Ivement? 
4) What was the tfiost positive aspect (s) of this new product 
development / introduction for you? 

5J What recomniendatiohts} do you have for htiilding mate 
teanrwork and personal satisfaction into the development / 

introduction process? 



6} What was the Tnost negative / frustrating aspect fs) of 
this new product developaent / introduction for you? 



7) What change (s) to the new product development / 
introduction process would have helped you to use your time 
more effectively / efficiently? 



S) what additional comments, concerns and recominendationa do 
you have with regards to the new product deVfilopjiient / 
introduction process? 



Rg. 5, Qiiestionnaire for /n -process project mtrospective, 
reviews. 
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Fig. 6. Deftcfencies identified by in-process project retro- 
spective reviews. 

deliverables and time estimates of less than 80 hours each. 

After a while, the R&D managers had access to an infm'- 
nial library of PERT charts on completed projects which 
they could use as a starling point for new projet;ls. This 
tended to improve the accuracy nf planning while reducing 
the work of doing it. [This is an example of the general 
principle that higher quality often costs less.] 

The product development process as practiced a I this 
division has several distinct phases. A procedures manual 
explains each phase and what requirements must be met 
to proceed to I he next phase. Without data like that show^n 
in Pig. 5, it is hard to know when something in the proce- 
dures manual should be revised. The retrospective surveys 
gave the R&D managers data showing where the process 
was deficient and which sections of the manual should be 
updated. This data transformed the task ol updating the 
manual from being thankless, vague, and i id i rule to being 
important, specific, and finite. 

Some of the other HP divisions thai have attempted simi- 
lar use nf project retrospective review^s are achieving simi- 
lar results. It was also found that an essential element lor 
the success and continued use of this typo of tool is leader- 
ship and encouragement from top management. 

Quality Function Deployment 

Quality function deployment (QFD) is a methodology^ 
that w^as developed to ensure that the voice of the customer 
drives the definition, design, and production of products 
and services. The QFD approach requires cross-functional 
cooperation— principally among the marketing, l^t^d!], and 
production functions— to collect adequate input on cus- 
tomer wants and competitive standing and to translate this 
information effectively into product design and production 
processes. This cross-functional cooperation is made more 
efficient and effective through the use of the so-called 
"seven management and planning tools/' '■^"" These tools, 
which include special types of diagrams, charts, and ma- 
trices, facilitate communication and consensus. 

One of these seven tools is a class nf matrix diagrams 
that are used in QFD to guide the planning process and to 
store the results of judgments and calculations that have 
been made. An example is provided in Fig. 7, hi this figure, 
the importance of want for each of the customer wants 
should be derived from customer research. These impor- 
tance weights are multiplied by the corresponding coded 
relationship strengths in each column and summed verti- 
cally to give the column importance weights. For example, 
in the first column, we compute 10 x 9 + 8 >f 1 to get 98 as 



the column importance weight. The degree of technical 
difficulty entry records team judgment about the relative 
difficulty (including cost, time, need for breakthroughs, 
etc.} of achieving the different technical objectives. The 
roof on the ''house of quality" is called the correlation 
matrix because it portrays correlations between the differ- 
ent technical parameters. For more information on QFD, 
see references 21, 22 or 23. 

QFD matrices and tables provide explicit documentation 
of the link between customer w^ants, competitors' solutions, 
and the characteristics of the product under dev^elopment. 
This explicit link extends through product specifications 
lo the processes by which the product wall be produced 
and tested. The QFD tables or matrices are easy to under- 
stand and easy to use to facilitate communication between 
members of a team. One result is that problems tend to be 
more effectively anticipated and resolved throughout prod- 
uct development. Design engineers have used the QFD 
documentation to trace a product specification to the words 
recorded from customers in the consumer research phase. 
This access to the voice of the customer has helped 
engineers make more intelligent trade-offs between alterna- 
tive solutions to the design probicmr"^ 

In the first phase of QFD, the product planning phase, 
one key task is to obtain importance ratings for the various 
customer wants [see the importance of want column in 
Fig. 7|. The importance ratings are usually obtained 
through a variety of sources, tools, and techniques includ- 
ing customer surveys, complaint letters, choice modeling, 
and other typos of consumer research. Usually the project 
team clusters the customer wants into groups of related 
items before trying to establish the importance rating or 
ranking for the customer wants. 

The QFD team then generates a list of measurable^ con- 
trollable characteristics (often called engineering charac- 
leristicsj that relate to the customer wants they .seek to 
satisfy. The relationships between these controllable fac- 
tors and the customer wants are documented in a matrix 
as in the upper center of Fig. 7. The project team places 
symbols or numbers representing the strength of each 
relationship in appropriate cells of the matrix (see Rj, in 
Fig, 7). 

This information is combined with the results of com- 
petitive benchmarking, w^hich is done from both the cus- 
tomer perception and technical product analysis stand- 
points. Numerical assessments of the relative importance 
of different engineering characteristics are made and a tar- 
get value is determined for each characteristic. In essence, 
the target values for the engineering characteristics define 
the desired product. 

At this point the project team focuses on design and, 
particularly, exploring alternatives to find a design that 
achieves the target values of the engineering characteristics. 
If trade-offs have to be made, precedence is given to achiev- 
ing the target values for the engineering characteristics that 
the team identified from the QFD chart as most important. 

In one of the more widely used QFD approaches in the 
U.S., the details nf the winning design are elaborated in a 
cascading series of three additional QFD phasesi design 
planning (parts deploymenth process plaiming, and pro- 
duction planning.^"* In the design planning phase, the key 
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QFD matrix displays engineering characteristics versus ihe 
parls that the design specifies. For process planning, a ma- 
trix is developed that shows the relationships between parts 
and the processes that will be used to obtain them. Finally* 
in the production plannmg phase, a table or matrix is 
de\%loped that shows how the processes %villbe controlled. 

One QFD matrix or table can sometimes be used for sev- 
eral related products. If consumer researc h has^ identified 
different market segments with different priorities tor the 
various customer wants in the different segments, then the 
same table can be used to define different products for 
different segments. It is a straightforward calculation to 
translate changes in importance of customer wants into 
changes in importance of engineering characteristics. 
Changes in the importance of engineering characteristics 
nr desired target values affect the evaluation of each specific 
product concept* 

QFD has been used in the design not only of hardware 



but also of software^ ^ and services."^ 

QFD does not eliminate Ihe need for managers to use 
other techniques to improve their project management. 
Post-introduction product reviews and in-process project 
retrospective reviews* as described above, help managers 
charged with at! phases of product development improve 
their understanding and effective use of techniques such 
as QFD and PERT. For pxample, managers need to know 
if they are adequately investing in consumer research. Posl- 
inlroduction product reviews can help answer such ques- 
tions. 

Concluston 

The development of successful new products is a process 
that itself produces a product— namely, a design for a prod- 
uct and for its associated manufacturing process. This 
paper has suggested that the product development process 
can be improved by using certain tools and management 
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processes for: 

■ Evaluating the perforraance of the process (break-even 
time) 

■ Studying the process and its results (post-introduction 
project reviews and In-process project retrospective 
reviews] 

■ Revising the process to achieve belter cross-fimctional 
communication, a good understanding of customer 
wynts and competition, and a clear view of interrelation- 
ships so that important factors or steps are not inadver- 
tently left out (QFD). 

The use of these processes and the data they generate 
has resulted in major improvements in R&D productivity 
in parts of HP. One crucial lesson from HFs experience is 
that top management letidership is vital to the successful 
use of the techniques described in this report. HP's top 
leadership has been effective in promoting the use of BET 
and QFD thiTJughout the company, Division general man- 
agers and R&D managers have asked for and used project 
retrospective reviews. Similar efforts that lacked such sup- 
port have not been successful, 

In the fulure we expect that expanded use of techniques 
such as those described above will improve the competitive 
position and possibility of success for organizations that 
use them. 
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DSEE: A Software Configuration 
Management Tool 

HP Apollo provides a software tool that helps to manage 
development and maintenance of the many components 
that make up large-scale sofmare systems, 

by David C- Lubkin 



THE DOMAIN SOFTWARE Engineering En\nronment 
[DSEE) is a configuration management system that 
is useful for managing large, complex software 
development and maintenance projects.* DSEE runs on 
the Apollo Domain operating system (Domain/OS) and is 
in use at over 6000 sites world-wide, including HP Apollo. 
We estimate that DSEE is responsible for managing over 
one billion lines of code. DSEE is also encapsulated in the 
new Softbench' lechnology. 

DSEE is designed to deal with the particular problems 
of large-scale software develo|)jnent. Some ot these prob- 
lems are w^orking on multiple development efforts in paral- 
lelr maintaining existing releases while vx'orking on new 
code, coordinating code and documentation, reducing the 
time it takes to build a programt and knowing precisely 
w'hich tools and versions of source code were used to create 
a binary file. DSEE unifies development and maintenance 
for large-scale systems [the largest so far is 11,000.000 
lines). It supports project development in a distributed 
computing environment, and works with any programming 
language or tool. DSEE is highly reliable ^ thanks to transac- 
tional file and database operations* store-ajid-forward mes- 
sage passing, audit trails, and time-proven fault recovery 
procedures. The latest version of DSEE. version 4, makes 
the configuration management capabilities of DSEE avail- 
able to a variety of non- Apollo systems. 
The major subsystems that make up DSEE include: 

■ History Manager. The history manager stores, controls 
and tracks source code evolution, and enforces concur- 
rency controL 

* Task Manager. The task manager plans and tracks the 
low-level steps taken toward achieving some high-level 
activity— for example, tracking the modules changed to 
implement a new^ feature. 

■ Monitor Manager. The monitor manager tracks people- 
oriented, rather than build-oriented dependencies. For 
example, it notifies users when alarms they set are 
triggered because components of interest are modified. 

• Configuration Manager, The configuration manager is 
concerned with system building. It also manages derived 
modules such as binary files or formatted text, 

■ Release Manager. The release manager archives execut- 
ables. and optionally, it can take a snapshot of the tools> 
elementSn and files used. An element is a file under DSEE 
source control. 

*DSEE is atso usahjl for amatl and simple projegts 



This article provides an overview of these subsystems. 
There is also a discussion of DSEE version 4 features that 
allow non- Apollo users to have access to DSEE capabilities. 

Version Control 

The history manager stores, controls and tracks source 
code evolution- It enforces concurrency control and securi- 
ty, and keeps a complete chronological audit trail of library 
modifications. DSEE views the evolution of a file as a 
directed acyclic graph [see Fig. 1), Any number of people 
may work on the same file concurrently by making new 
branches- Their work ma}' be kept separate or merged 
together with a three-ww merge command (Fig> 2). The 
trunk is also considered to be a branch, and it is usually 
referred to as the mainline. 

In merging versions on two branches together. DSEE com- 
pares the tw^o versions with their nearest common ancestor. 
If work in a small section of the file changed one branch 




Mainline 



Temporary Branch tor 
Group Work 



w3 l.imi, 



Long-Uv&d Srar^ch 






Temporary Branch 
for Private Work 



(^ 6 



Rg. t . A portion of a graph showing ths evoiutiori of a typicsf 
moduie in DSEE. The numbBrs in the bubbles repfesent \/er- 
ston number B and the bracketed text represents version 
names. The double soiid lines represent mainlines, the single 
solid lines represent branches, and the dashed lines repre- 
sent merges. Without the cattouts, this screen ss provided in 
a window via the DSEE show derivation command. 
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Base Version 



I «W (v3iil^Wi«'^; 
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[JAgr sJon 1 | 



metgc: fooc wS.S.tiL'gftx-with foo-c 



Version 2 -#- 



) [versiQn 3 [ 



Rg. 2 . The exec ul/o/i of f/ie thf&s-wBy /r^ e i' j^ c ^ u ,• : . ; ; , ^ , .. J f emits 
if] merging version 1 and version -2 and cf eating version 3^ 

rtjlative to the ancestor— and didn't change the Hquivalent 
location in the other branch — DSEE auloinaticaiiy selects 
the new modificalttjns. If both files liave changed relativt> to 
the ancestor. DSEE presents both sets of changes in a win- 
dow. Users may pick one or both sets of changes, which are 
tiien copied to a winduw containing the merged file. Thy 
user can furthi^r edit the tile in the merged window. Fig. 3 
shows the DSEE screen during a merge operfitioii. 

Branches hsve names like v3 Sbugtix or Add Buzzwords. Ver- 
sion!^ or generations on a branch iiave version numbers, 
but can also be given one or more names (e.g., version 1 
of v3.3.bugfix in Fig, 2 has four namesi. The evolution of a 
module can get v^ery complicated. That's why DSEE has a 
command called show derivation tlidt jillows tlie user to dis- 
play graphically the strLicture of a module's evolution. 



Including branch points. Figs. 1 and 2 w'ithout the cal louts 
are examples of what the show derivation command provides. 
The sliow derivation command also has options to prune por- 
tions of tlie displayed structum. 

Versions are stored together efficiently. DSEE's inter- 
leaved forward deltas and compression allow 50 to 200 
versions of source code to be stored in the same space as 
two ordinary text copies. Binary files can be stored under 
DSEE. but they are not stored as compactly as text files. 
Any version of either text or binary files can be read in a 
single pass through a DSEE history file. 
Transparent Access lo Versions. Because of the Domain 
operating system's typed file system.** any DSEE element 
can be read directly* vvithout checking it out from the 
library, either from an Apollo system or across a transparent 
remote file system like NFS^ DECnet. or Domain/PCL This 
lets ordinary applications like cc and trotf operate on objects 
under DSEE control without modification. 

DSEE files are typ'i^ case_hm. When asked to read a 
pathname !hat ends v\ith a DSEE file's name, the case_hrTi 
type manager returns the most recent version on the main- 
line. If the user wants to read some other arbitrary version, 
the version can be explicitly named or implicitly associated 
with the original file. If the pathname continues beyond a 
DSEE element, the case^lim manager interprets the remain- 
der of the pathname as a sequence of branches and gener- 
ations. This extended naming does not work across all 
transparent remote file systems. Some remote users have 
to u.se the DSEE fetch command, W'hich refers to versions 
with a similar syntax. All users can use the read command, 
which puts any version into a read-only Xll window. 

The following examples, which are derived from Figs. 1 
and 2, illustrate the different t}rpes of pathnames that are 
used to access different versions of mod ides in DSEE. 
» Most recent version of the main line of descent 

fooc 
■ Specified version number on the main line of descent 

loo.c/193 

'*UnaeT- Domau'DS, eacn tile nas a type, ana escn typo naa an as^Qcial&d rnar^age^ thai 
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Fig. Z, A screen showing how 
DSEE dfspiBys the status of a file 
while it is being mergep. 
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■ Most recent version on the specified branch 
foo.cA^ . 3bugf ix/bfezak 1 

■ Specified v^ersion iiymber on the speciBed branch 
f oo,e/v3. 3bugfix/2 

■ Specified version name 
foo.e/V3. 3bugfix/lv3. 3, 2.alpha] . 

Users can also implicitly refer lo a collection of versions, 
like those used to build some binan', or a specific named 
version of each of their files. In Domain/OS, the user can 
create a shell that is bound to that collection. Whenever 
Bles are read from that shell, the case_^ manager will 
access the particular versions that had been specified. 

In the case whore DSEE files are accessed from a non- 
Apollo computer, tbe mechanism that binds versions to 
shells does not work across most transparent remote file 
systems. Therefore^ the user has to access the desired files 
through a special directory whose presence indicates the 
version the user wants. In the following example. vq6cro6b 
is such a directarv- Requests to read below it are handled hy 
the vswitcti type manager, which reestablishes the versioning 
context and then hands the request on to the case_hm type 
manager. 

Domain /OS pathname: 

emacs JJ1 ireball/my li brary /ut J Is.c 

HP-UX pathname: 

emacs /apo (lo/zo rro/sys/nodedata/tmp/vq6cro6b/myli brary/u ti ts .c 

When emacs on HP-UX opens 

apol lo/zorro/sys/nodedata/tmp/yq6cTO6b/my 1 ibra ry /util s. c. 

the request is passed to the HP-UX operating system. HP-UX 
recognizes that /apotlo is an NFS mount point and issues a 
series of NFS requests thai should result in the desired file 
being opened. Eventually, the remainder of the pathname 

ro rro/sys/nodedata/tfnp/vq6cro6b/m y li br ary/utlls .c 

IS passed to the Apollo NTFS server which submits the 
request lo the Domain/OS 1/0 system. When the I/O system 
encounters the object ^/q6cro6b, which is file type vswitch, it 
loads the vswitch type manager. The ^switch t^^pe manager 
uses the rest of the pathname and information stored in 
the vswitcti object to establish the proper versioning context, 
and then passes the request to the case_hm type manager. 

Note that on Domain/OSr the file system of any indi- 
vidual Apollo computer is accessible as a subdirectory of 
//. Similarly. NFS users can mount the entire Apollo net- 
work at one mount point (/apollo in our example). These 
two mechanisms for implicit reference to versions are inte- 
gral parts of the configuration manager described later. 

Project Management 

Frojii^ct nifJiiagemont capabilities are provided In HSEBI 
by the task manager and the monitor manager. The DSEE 
task manager plans and tracks the low-level steps taken 
toward achieving a high-level goal» like fix bug #1332 for 



Locktieed. It automatically records DSEE actions made on 
behalf of the goal, like builds or replaces. It can also be 
used to record non-DSEE tasks to do or that have been 
done, like review Chapter 5 of the new doc. For tracking recurring 
activities, new tasks can be created using a task tem:plate 
fscility. A task template facility is a set of services in DSEE 
to manage task templates. A task template is a template for 
a new task. For example, suppose the task system is used 
for bug tracking. A task template can be created that con- 
tains the standard set of steps used when tracking a bug. 
When there is a new bug. the task cam be initialized from 
the template. 

In the short term, task records can be used by team mem- 
bers and managers to track progress toward goals. Later on, 
they provide a historical record that can be useful for resolv- 
ing similar problems and for helping new team members 
iearn what has been done and what steps were taken. 

All of a user's tasks are collected on a personal tasklist. 
For example, the following tasks might be on taskiist too. 

7: Created 16-Jan-1990 10;50 in library 

7/hel p less/case/from _ dean/case _ cm " ■ 
NFS/vs witch performance improvements 

6: Created 8-Jan-1990 12:27 tn library 
7/hel pi es s/aa se/f ro m _ d e a n /case _ mgrs": 
V4 HCM bugs 

The monitor manager tracks people-oriented dependen- 
cies. The user describes what DSEE elements to monitor* 
who can or cannrjt activate the monitor, and what should 
happen when the monitor is activated. The monitor then 
remains dormant until it is triggered by changes to the 
elements being monitored . When the moni tor is triggered 
it may; 

■ Send a mail message to one or more users 

■ Add a new task to some user's taskiist 

■ Send an alarm window to anyone on the network 

■ p]xecule an arbitrary shell script. 

One example of monitor use is that our technical writer 
keeps a monitor on the module that handles DSEE's com- 
mand syntax. This way the writer does not need to rely on 
tht^ DSEE developers to know when changes are made that 
affect the documentation. 

Some customers use moniEors to convert from RCS or 
sees to DSEE. Typically, custpmers axe cautious and only 
convert one group at a time. If that group had been sharing 
their SCCS files with other groups, they could set monitors 
on all their DSEE elements. When a monitor is triggered 
by the creation of a new generation of a file, it would run 
a shell script that updates the corresponding SCCS file. 

Configuration Management 

The central concern oi DSEE configuration managernj^nt 
is to provide a reliable and complete permanent record of 
what sources, tools, and translator options were used to 
build a program. This is one of the primary characteristics 
that distinguishes DSEE from other configuration manage- 
ment tools. DSEE uses this precise description to improve 
personal and group productivity, but never at the expense 
of correctness. Users can share binaries with each other 
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when the descriptions of what ihey want tn build match. 
Their work is kept isolated when they don't match. DSEE 
will minimize the nnmber of compiles required to build a 
program and how long they take. 

The configuration manager separates the descriptions of 
the structure of the user's program (i.e., the sysleni model) 
and the specific versions the user wants to build at a par- 
ticular time (i.e., the configuration thread). 
System Models. A system modt^l is a set of files that describe 
the static structure of a program or system. It is written in 
a special declarative and block-structured language. Sys- 
tem mode] components may either tie DSEE elements or 
external, nonelement files. For each component of the sys- 
tem, the model expresses: 

■ Source dependencies (i.e.. what the source includes) 

■ Trans iat ion roles * (i.e. . how to compile the component) 
m All possible translation options {e.g., -debug, -opt) 

■ Tool dependencies (i.e.. tools required for the transla- 
tion) 

m Subcomponents that must be built first. 

The model language supports conditional constructs that 
may be triggered by target system characteristics. 

A utility is provided w^ith DSEE to help the user create 
a system model. It determines the include file interdepen- 
dencies by looking at the source code and creating a skeletal 
system model. The user will still have to tell DSEE hoiv 
to build the program and fine-tune the model. Pig. 4 shows 
a small portion of a system model description. 
Threads. Configuration threads describe which versions 
and translator options to use when building each compo- 
nent in the system model (see Fig. 5). By changing threads, 
users can quickly switch among new development projects, 
fixing hugs in old releases, and making special versions 
for particular targets or customers. 

Configuration threads may be: 

■ Explicit [e.g.. use version 5] 

■ Dynamic [e.g., use the most recent version) 

■ Referential (e.g., use the same version used in rev2) 

■ Contextual (e.g., use x.h[7| for P, otherwise x.h[6]]. 

Fig. 5 illustrates how two engineers can build similar, 
but not identical configurations of the same system by using 
different configuration threads. Engineer A Is using a thread 

^TransJHtion oifes are sJyli^ecf shell 3cr'jpf& itial descobe now 1o DuiJd a system mtjdei 
component. Thty are BKacHy lik& ■s^flll achpEs exCJEjpl that tn place cit many psjh names 
anq cQjnpiler options,. there are mapros: 



System Model 

mociel myjprogram 

element lexerr.c = 
hosi_\fpe hp-yK: 
depend s.sDurce 

y.h -fi i\b2i 
translate 

ec —a %re5ijft 'as 
%done 
enc^ or lex^rr.c; 



+ 



Contiguralion 
Thread 

-reserved 

[beta] -Hhen_exisls 

-use^options -debug 

[releA&e_3j 



Bound Configuration 
Thread 

texerT.cflSj 
)t.h[7] 
y.hpal 
-debug 
compiler v&.2 



Fig. 4. An excerpt from a system modBl 0escmtion and Its 

relamnship to a conffguratton thread and the resulting bound 
configuration thread. 



that tells the confignration manager tu Inllow these rules; 

1- For the file alpha, use the most recent version on the 
mainline, 

2 - For e V ery other file , us e t h e v ers i o n na me d V 2 ( vy rs i o n 
3 from beta and version 6 from gamma)- 

The mainline for file gamma is reserved in engineer B's 
working directory. Engineer B uses a confignration thread 
thai tells the configuration manager to follow these rules: 

1. For each file used in the system, if it is reserved, use 
the version in the ^vorking directory- 

2. Otherwise, use the version named V2 for each file 
(version 3 from beta and version 8 from alpha). 

There is also a modei thread that applies to system mod- 
els. Model threads are usually stored within a DSEE library 
so that users have a precise description of the structure of 
a program at any time in its history. They are often com- 
posed of several files, or model fragments, The model 
thread describes which versions of model fragments and 
conditional compilation options (targets) to use when inter- 
preting the system model. One use for targets is to switch 
between different hardware platform^s or operating system 
versions. At Apollo » the system model for the Domain/OS 
operating system supports over a dozen different hardware 
variants. 

Bound Configuratiaii Threads, DSEE combines the system 
model and configuration thread to make a bound configura- 
tion thread (see Fig. 4), It is a permanent record of the 
options, versions of sources, and tools used to build a com- 
ponent. Bound configuration tiireads are kept along with 
derived objects and binarleH in special directories called 
pools. When the user types buifd, DSEE looks in the pools 
for bound configuration threads that matc;h the components 
the user asked to build. DSEE keeps a number of earlier 
builds in the pool and attempts to reuse them. If it can't, 
and the pool is fulh the least recently used build of that 
component is purged to make room for a new one. This 
lets the users share binaries, thereby reducing the nuniher 
of builds to perform. On the other hand, because the bound 
configuration thread gives such a clear picture of what 
makes up a particular binary, only binaries that match the 
users' needs are sliared. 

DSEE lets the user declare that some compiler options 
or source versions are critical and that others aj'e noncrit- 



Engineer A Is Working on Alpha -i- V2 
^ V Engineer B Is Working on Gamma t- V2 



\ 



# if 



® 





Afpha 



Beta 



■■Hi 



Gamma 



-^J 



Fig. 5. An Bxampie of conffguratton threads. Alpha, beta, 
and gamma are fites and the nun^bers represent different 
versions of the files. 
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Rg. 6. Display showtng parallel 
builds in progress. 



ical. If a critical depeindency changes, DSEE will rebuild 
the module- If a noncrilical dapeiidency changes, DSEE 
will record what compiler option or source version was 
used* hut It will not rebuild the module. There are also 
override mechanisms through w^hich the user can force 
DSEE to rebuild even though the bound configuration 
thread doesn't call for a build* or not to build when DSEE 
thinks it has to. 

Before DSEE starts building it sequences the required 
builds according to theij interdependencies. As the user's 
translation script executes, it reads the desired version of 
each DSEE element directly out of its library. After the 
program is built and debugged, the user can make a release, 
or permanent snapshot of the bound configuration threads, 
binaries, sources, tools » and system model ttiat make np 
the program. With this feature, W'hen customers report a 
bug iwo years later, the engineer repairing the code can 
rebuild the same bits, plus the fix. 

Version 3 of DSEE added support for parallel building 
on more than one Apollo compuler at the .same time. DSEE 
tracks the CPU utilization of candidate build computers, 
and starts builds on the most lightly loaded machines. Fig. 
6 shows parallel builds running on several machines, The 
performance improvement provided by parallel building 
can be substantial. For example, the time to run the Ada 
validalinn test suite drops from SO hours to 1 7 hours when 
it is built in parallel. 

If an executable is compiled with an arbitrary collection 
of stdio.tis. it might take weeks to track dowm a problem 
caused by inconsistency in the include file. DSEE ensures 
that all builds use the same set of tools and system include 
files by building relative to a reference directory. 

Heterogeneous Configuration Management 

Many users want to use DSEE to dtsvelop software for 



non-Apollo platforms. To fill this need we generalized con- 
figuration management to handle heterogeneous configura- 
tion management. Version 4 of DSEE supports other systems 
that are based on the UNIX* operating system. Fig. 7 shows 
the setup for heterogeneous configuration manageTnent. 

DSEE can be used to develop softw^are for non-UNIX 
targets as well; it*s just more involved. Since a translate 
rule is an arbitrary' shell script, it can copy sources over to 
a non-UNIX target, invoke a shelK and copy the results 
back into a pool. 

Host Types. To handle heterogeneous configuration man- 
agement, each system model component has a host type, 

»UMiX is a registered tfaiiemark of UMIX S/SlB-nr» UtooralofjSB in the US.A and olher 
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JhearchitecMe for DSEE tn a heterogeneous environ- 



JUNE 199t HEWLETT-PACKARD JOURNAL 81 



)Copr. 1949-1998 Hewlett-Packard Co. 





System: //giiardian/dsec/dscc From y/lirpball/Kjbkiii/srlO.:?/conlex1 
Model: d5Pc.5inl£2aGj & //guardiaiWrtscc/ciise cm 
librarY: //case 9/dsce.dir/case 1 


Qu^ System Relffase Pt>ol 


Ta^kJiHt ta^k Form Monitor 


Help 


Madet Bcamp OiiMd lhrt?ad 


IJhrary F^lernertt Branch Version 


Misc. 








i !;^ 


All librail£^ df^clcirtfd In tht^ qurrent iTi<>(ial 




■^^ Dlifilay objeci in icon iirea 

■^/' Display ohje c^: In icon area afid select It 






//cdseS/dsre ilir/srrrc. ;>Tr>c(ib 

//case a/dbee.dir/case 1 

//gu ardi an/dse e/c ttse cm 

/j'gii(*rdian/dSE&/case_mgrs 

//giiurdiiin/diice/loola 

//case _9/di 5 k3/d3 m.dir/sysii lis 

//case 8/dse e.dirfcas c _n ui 

//mis c sprver/mi sc 1 /ios/m grs/ca se 

//m Is c server/misc 1 /! os/m grs/dfi Ie 

//misc serve r/misci/ios/ir^s 


/ 


^ 


Current HCffti-; Iflt;, CQNIEHT ie "//fireball/ U i' 
CufretPt l-rjIlEL is "ds^et-sm 112961 a //gyan-. i; 

the iahe a^ the i/^'"3iori usred trf ""i 


^ 1 


-- 


C^inJirm 


Cancel Help .,. 












[^ 


1 


^ 














P3£E- |1 









Fig . B. DSf jE graphics} user inter- 



fact 



which is a user- defined taxt string that describes the class 
of machine the translation should run on. It reflects the 
distinctions between machines that the user wants lo use. 
Host types can he used to make very fine distinctions, like 
DN45O0 wfth FPA board, or broad groupings like UNIX. The 
UNIX keyword might be u.sed for translators that produce 
portalde output, like yacc or troff. The only host type that 
is predefined is apollo. The following is an example of a 
user-defined host table. 

# /s y s/d see/dsee _ co nf ig/hosts 
# 

# host^type OS manager build manager 



apallo 


dDmain_os 


dds 


prism 


domam_os 


dds 


dn4500_ w_fpa 


domain _ OS 


dds 


hp-ux 


posix 


mh 


syn386i 


posix 


r^ 


uniK 


posix 


rsti 



Each host t^rpc has an associated OS manager, which is 
used to manage derived objects and trans kite pathnames ^ 
and a build manager, which is used to select build com- 
puters and start com ptl at inns. DSEE V4 provides OS man- 
agers for Domain/OS and POSLX. and build managers lor 
Domain network services (dds) and rsh | remote shell]. Each 
hast type also has an associated list of build computers. 
DSEE picks one. and then starts the build on the foreign 
machine. If additional builds are required, they <:an proceed 
in parallel 

Split Pfjols. The bound configuration tlu^ead and derived 
object sections of a pool can optionally be split into separate 
directories. For non- Apollo users, this means that users 
can use their existing investment in non- Apollo disks to 



store binaries, Deiiending on the user's netw^ork coniigura- 
tion, this can also resuh in faster load (/bin/Id] times. When 
there are IJSEE managers for non-lINIX operating systems, 
split pools may be essential, since many have file system 
attributes that have no equivalent on Domain/OS, 

User interface 

Version 4 also comes with a new user interface {see 
Fig. B). It is based on the X Window System, and conforms 
to OS F/!V[olif standards." As such, it can be used remotely 
irom any machine that supports X. The user interface is 
ob j e c t- r 1 en te d . Objects t;a n h e b r o w se d . resulting in icons 
being copied to a desktop area. DSEE commands can be 
applied to selected icons through associated menus, picked 
from a menu bar, or entered froni a textual command wnn- 
dow^ When DSEE needs more information, it pops up a 
dialog box. The boxes are preseeded with likely option 
values. Some of these dialog boxes support multiple itera- 
tion, which allows the same conunand to be issued 
repeatedly, each time using a different list of arguments 
(Fig. 9). All commands result in entries in a command 
historVi from which they can be perused and reissued. 

DSEE is still accessible through earlier user interfaces: 
a command line interface based on Domain/ OS display 
manager pads and a serial I/O interface which is used when 
the input stream is not a window. There are also tw^o pro- 
grammatic interfaces that allow DSEE commands to be 
intermixed with C or shell commands. When the binary 
library /lib/dseellb is bound into a program, the program can 
issue DSEE commands. This callable interface was used to 
write dsee„ serve r_c, an example program shipped with 
DSEE. A client program, ds, sends IPC messages containing 
DSEE commands to the server, which executes them 
through the procedure dsee_Scmd. The result is that shell 



B2 HEWLETT-PACKAFID JOURNAL JUNE 1991 



)Copr. 1949-1998 Hewlett-Packard Co. 



^ - into (altemate taro^* 
^ - r (repiact t<sfg^ flic i 



reserve brant: h 



i^biiild.pas 

bui (dj nvo ke_i ntertu d c s.p as 
•'"ild invoke tralt.h 




^ F- <^ mm e iirt fd^ not query far <^i[^mmei#s^ = ^ - 
V" n c ( ito not query for co m me nts ] if 



CpJ>firfVt : 



m 



Rg, &, A diafog box that provides 
multipie iWr^tion, The box con- 
tains a scroUabiB wmdovj Q(mtam- 
mg Blerrmnt names Users can 
seiect one or more of these names 
and DSEE wiff issue a separate 
reserve branch command for 
each sB(ecied element name. 



rontrol constructs can be used to postprocess the results 
of DSEE commands. 

Conclysion 

DSEE is a powerful tool for version control, configuration 
management, and project management for software proj- 
ects. While it is often used on small projects, it is clear 
that the product'-^ particular strengths are in handling the 
complexities inherent in large projects developed by teams 
of programmers. 
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A Mechanism to Support Parallel 
Development via RCS 

HP's Imaging Systems Division uses f/ie HP-UX revision 
control system utility, RCS, to implement a configuration 
management system that allows stable, released software 
to remain unchanged while modifications are made to some 
of its components. 

by John W. Goodnow 



AT VARIOUS INTERMEDIATE checkpoints during 
the product development life cycle, it usually 
becomes necessary to stabilize the software for 
events such as field trials and final functional verification. 
A conflicting, but equally important requirement Is that 
development for future checkpoinls and releases must be 
allowed to continue while baseline* software is kept stable. 
At HP\s Imaging Systems Division IISY). the need for this 
parallel development is also driven by continuous field 
trials and frequent software upgrades. ISY produces real- 
time embedded systems software for the control of 
ultrasound inslruments (primarily diagnostic cardiac imag- 
ing). A typical instrument cony is ts of several subsystems, 
which range in size from 700 source files to la ling 60 
KNCSS** to 1200 source files totaling 200 KNCSS. 

This article describes a simple mechanism, based on the 
HP-UX platform and the RCS (revision control system] util- 
ity, for effectively achieving parallel development capabili- 
ties and implementing baseline configuration management. 
The mechanism described is reliable, robust, and simple 
to use and administrate. U is widely used by the software 
development groups at ISY, 

Although the parallel development mechanism described 
here can be integrated with almost any software develop- 
ment environment in which RCS is used, the implementa- 
tion at ISY is based on an in -ho use software development 
environment built over the last four years. This underlying 
environment, hereafter referred to as the ISY SDE. or just 
SDE. runs on a distributed network of HP 9000 Series 300 
workstations and uses RCS and nmake tools to realize revi- 
sion control and build management. To understand the 
workings of the parallel development mechanism, it is 
important first to understand the major underpirmings of 
the ISY SDE. 

The ISY Software Development Environment 

The ISY SDE is essentially an extensible directory struc- 
ture and a rich set of support tools that provide the develop- 
ment group with revision controj and build management. 
In additioUt support is provided for independent private 
development, in which individual software engineers can 

*ln our environment the bg5siir>9 contajna aJf Uie components (soonce code. executaWes, 
oocurpenEaticMi, eic,} fronn wnien the final product ts creaiect. 
"KNCSS = thousand lines of nDncommeni sourte slatements 



link local copies of modules under development with stable 
baseline software. 

Directory Structure. In generah a particiilar instance of the 
ISY SDE is rooted at a director^^ consisling of three logical 
components: tlie super root^ the name, and tlie revision. 
For example, in the SDE rooted at /users/prism/dss/main, the 
super root is /users/prism, the name is dss, and the revision 
is main (see Fig. 1). Each instance of the ISY SDE has an 
area for source (and header} files under RCS control as well 
as a separate area in which individual software engineers 
can keep locah working versions of any of those source 
files (work directory in Fig. l]. 

Revision Control Based on RCS. As stated above, the revi- 
sion control aspects of the ISY SDE are handled by RCS. 
Without considering parallel development, the use of RCS 
in the SDE is quite straightforward. The SDE contains a 
large body of source files, al! of which are under RCS con- 
trol. At any given lime, the latest revisions of these files 
make up the mainline configuration. For projects in the 
ISY development !ab* the mainline usually corresponds to 
unrel eased software in various stages of development. 

During the course of development, software engineers 
can check out mainline files, modif^^ these files, generate 
and test executable software based on these modifications, 




Fig. 1 . An exampfB of an ISY software development environ- 
msnt direotofy structure. The incEiid© and source ds rectories 
contain the standard, globally available softv^are. All the fllBs 
in source are compiled nightly to produce a standard dmiy 
executable, which is placed in the directory /toad. The files in 
the work directory are completely pnmte to the individual 
engineers. 
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and check the files back io. These modified files become 
part of the mainfine %%heii they are checked back in. These 
operations are the standaxd checkout (co) and checkin (ci) RCS 
commands- 

Build Management Based on Nmake. The iSY SDE uses the 
nmake program to manage the buiid process. Nmahe ks very 
similar to the standard make program, bu! it is substantially 
more flexible. For example, nmake automaticaliy evaluates 
and maintains dependencies introduced by header files. 

For a typical ISY project, the mainline is always butlt 
nightly, and is rarely, if ever, built during the day. This is 
because the build process takes several hours to complete. 
Building the mainline during work hours not only leaves 
the project's object files in an inconsistent state for long 
periods of time, but also introduces unacceptable loading 
on the workstations executing the build. 
Standard Directory Types. The source files that make up 
the mainline of the project are stored in a hierarchical 
directory structure. This ensures that each source directory 
contains a set of functionally related files, and no director}^ 
contains an excessive number of files. Header files are kept 
in a global header directory or in individual source direc- 
tories according to their scope. 

Although the hierarchy and allocation of .source files to 
directories are arbitrar}^ and completely at the software 
engineers' discretion, the organization of an individual 
source directory is highly structured. This structure is 
imposed by the SDE, and it exists to strike a good balance 
between the capabilitie.'? provided and ease of use. A source 
directory with this SDE-imposed structure Is called a stan- 
dard directory. 

Several different types of standard directories can he 
configured* and all standard directories are class! Bed 
according to two attributes: major and minor directory type. 
The major directory type determines the combination of 
rmision crmtrnl and object file generation services pro- 
vided, while the minor directory type selects the compiler 
family to be used for object file generation. 

Each major directory type is tailored for certain require- 
ments [see Fig. 2). A revision control standard directory is 
used to hold header files, which don t need any object file 
generation. A source standard directory is used to hold 
source files which must be under RCS control and require 
object file generation, such as compilation and assembly. 



A working standard directory provides object file genera- 
tion ser\ices only, and is ideal for software engineers \insh' 
ing to modi^', compile, and test their own local versions 
of source files. The major directory types and their 
capabiHties are summarized in Table 1. 

Table I 
Major Directory Type and Capabilities 

Major Revision Object File 

Type Control Generation 

Source X ^ 

Working 5C 

Re vis i on Con tr o 1 X 

Examples of different minor director^' types include the 
native HP-UX compiler and assembler family and a 6800D 
cross compiler and assembler family. The HP-L^X minor 
directory type is used for development of host software 
designed to run under the HP-UX operating system, while 
the 68000 cross compiler minor directory type is used for 
development of software targeted for execution in embed- 
ded systems. Moreover, the method of handling minor 
director^' types is fully extensible, allowing plug- compati- 
bility with additional minor directory types defined by end 
users. 

One inherent feature of a standard directory that greatly 
enhances its ease of use, at the possible expense of end 
user flexibility, is that all files in a given standard directory 
with a given suffix are treated identically. This means, for 
example, that all C source files in a specific standard direc- 
tory will be compiled with the same command line. Fur- 
thermore^ generic makefiles with a standard set of rules 
are used far abject file generation in all standard directories. 
This eliminates the need for software engineers to create 
or maintain makefiles. 

RCS Features 

Supporl lor parallel development draws heavily on three 
adv'^anced RCS features: branching capabilities^ directory 
links, and symbolic names. Although all of these are fully 
supported and documented RCS features, each will be 
described briefly below. Refer to the HP-UX reference man- 
ual for a complete discussion of these features. 



users prJ&m dss mam 




too h.v Makefiles and 
tjsr.h.v Driver Scripts 



bar.o 



foo-cv Makefiles and 
hgr.s,v Driver Scripts 



fooo 



Makefiles and 
Driver Scripts 



Revision ControJ Standard 
Directory 



Source Standard 
Directory 



Working Standard 
Directory 



Fig. 2, Slandard directories. 
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Head 




AT 



Indicates Absolute Storage 
Indicates Differer^tial Storage 



Trunk or Mainline 



Fig. 3- BranQhing structure of an 
ffCS file. Absoiuie storage means 
that every fine of the particular ver- 
sion !s stored. In RCS the head ts 
the only version stored absolutely. 
Differential storage means that 
only the changes from the prey sous 
version {i.e., diffsin HP-UX r?o/r?eJ7- 
clature) are stored. Typically, this 
consists of a series of added ar^dl 
Of deleted lines and associated 
line numbers, which when applied 
to an Bt^solute version results in a 
new absolute version. 



Branching Capahililies. Each RCS file (an KCS file is a file 
ending in ,v] has a ti'unk, and optionally, a number of 
branches. The trunk has a two-field revision number [e.g.* 
1.25, 2.1]. Branches have a 2n-fielfl {n ^ 2] revision number 
(e.g., 1.25.1,1h 2.1.1.3, 1.1;1,:m.1). The latest rcvi^^inn on 
the trunk is called the head. Fig. 3 illustrates these branch- 
ing relationships. 

This structure closely corresponds hi llie ISY method of 
splitting off branches for releases, trade shows, clinical 
trials, and other checkpoints, The parallel development 
mechanism built into the SDE uses these branching 
capabilities to allow RCS to manage branching on a tile-by- 
file basis. For a subsystem with muhlple revisions, al though 
there are multiple development trees, there is only one set 
of RCS files located in the mainline tree. Each RCS file in 
th^ mainline tree holds all possible configurations of its 
corresponding source file. Furthermore, since there is only 
one set of RCS files, it is unnecessary to copy any RCS files 
when a new tree is split for parallel development. Instead, 
pointers to RCS directories are copied. This is achieved 
via the directory link feature described next. 

One final note about branches is that they are only created 

u sera g&od now 



RCS 




PCS 



\ I 



Lui 



IBWBWBBg- ^^ RCS Directory Link 



Fig. 4, Use of RCS directory links. Only one copy of fllBS 
toox.v and baj.s,v fS needed. Other directories contain a file 
RCS which contains a path to the directory where these files 
exist. 



when necessary, which is when conflicting modifications 
are made to the same file during the course of parallel de\'el- 
opment. Extremely stable source Hfes. which are rarely 
changed, are very likely not to have any branches at all 
regardless of the number of parallel developmenl trees. 
Direclory Links. RCS directory links are fully integrated 
kite the ISY SDE, These directory links allow multiple 
directories to be created for checkout and compilation, all 
based on a single mainline RCS directory. RCS links are 
created by embedding a path to another RCS direi:tory in 
a regular file with the name RCS. Fig. 4 shows a simple 
use of RCS directory^ links. Directory links may be chained, 
and RCS will follow a chain of up to ten directory links to 
reach the actual RCS directory. Diret:tory links should not 
be confused with HT^-UX symbolic links; the tw?o are com- 
pletely separate features. 

Symbolic Revision Naming. The frnal RCS feature used to 
support parallel development is the ability lo associate a 
symbolic name with a particular revision of an RCS file. 
Once a symbolic name is created, revisions can be selected , 
checked out, and checked in using the symbolic name 
rather tiian a specific revision number. An RCS file can 
have any number of symbolic names, and multiple sym- 
bolic names may also refer to the same revision. 

ISY implementation 

The RCS features described above are used to implement 
the ISY SDE configuration management system. Basically, 
this involves creating a split tree for parallel developmenl. 
The split tree has the same super root and name as the 
original tree, hut has a different revision. The overall direc- 
tory structure of the split tree is the same as that of the 
original . Fig. 5 shows an e.\ample of a split tree based on 
the directory stracture described earlier. 

The support provided by the SDE provides as much trans- 
paxency as possible, so that for most cases, individual 
software engineers need not be concerned with low- level 
details. For example, check in and checicQut of RCS tiles 
in the split tree work the same wmy as they do in the maln- 
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users pfismdss 




/ \ 

Fig. 5. Directory structure for mwnifne and split frees. 

line tree with some in frequently occurring exceptions, 
vvhitih are described later. This is possible because the RCS 
options required to select the proper revisions for checkout 
and check in are supplied automatically by the SDE. Thus, 
this operation is transparent to the software engineer. The 
parallel development mechanism is recursive in that a split 
tree can be created from the mainline tree as well as from 
another split tree. Masterfiling* a split tree is fully sup- 
ported. This is a common operation, as splits are frequently 
created for sofrware release. 

SpEiEling a Tree- To split a tree for parallel development, 
the to 1 lowing operations must occur. 

■ All user-contributed source files in the original tree must 
he under RCS control. 

■ All RGS files in the original tree, whether this is the 
mainline or a previously split tree* are given a symbolic 
name, which is defined as the name of the split. The name 
of the split will hereafter be referred to as split ...name. 

> The original tree is cloned over to a new tree rooted with 
the split _ name. In rmr exampk^ directory structure given 
in Fig. 5» the Ajsersyprism/dss/main tree would be cloned 
over to /users/prism/dss/mO |mO is the split., name). This is no 
ordinar^^ clone, hfnvHVer. The directory structure of the 
original tree is cloned verba I im, bul in terms of RCS 
files, a virtual copy of the original tree is made, with 
RCS links being generated in the new split tree pointing 
back to corresponding RCS directories in the original 
tree. In olher wordK, when a split tree is created, no RCS 
files are copied, but RCS directory links are created 
instead. 

■ The RCS checkout and check- in options for the Kplit tree 
are modified la refer to the symbolic names (orsplit_name) 
created in the previous step. 

■ The new split tree is booted, which means it is turned 
into an independent environment which can be entered 
and used \iibl like the environment c:ontaining the orig- 
inal source tree. The hrjot process consists of building 
all the system tools and configuration hies in the new 
sp i it environment , 

■ The new split free is built. Since this step requires check* 
ing out and compiling all user source files, which is a 
lengthy process, it usually occurs overnight. 

s The new split environment is now ready for use. It is 
entered as a separate development environment. Develop- 
ment can proceed independently iji both the [jriginal 
and split environments. 

'Masferiiling Is ihe process cf scoring alf llifas in an envif onmenf to jape so ii^al the exflcutabto 
can hf- r{:-r.r,T,r,\nir,iGti oHIJne on an{?th&r Syatem 



Checkout and Check In with Split Trees. In most cases, 
making a change to a file in a split environment is no 
different from making a change to the same fUe in the 
mainline. The commands used to check out (co) and check 
in (ci) the file are the same in either case. To provide this 
functionality, the user is not allowed direct access to the 
CO and ci RCS commands. Instead, the SDE provides two 
interfece scripts called envco and envd. The interface scripts 
intercept user command lines, add additional options to 
the user commands, and then pass the concatenated string 
onto RCS. For example, suppose it is necessary to modify 
the file foo-c in either the mainline or a split. Table 11 sum* 
marines typical user command lines, and show^s the resul- 
tant commands issued for both mainline and split trees. 

Table II 

User versus Actual Command Lines 

for Mainline and Split Trees 



User Command 


Actual Command Lines 


Line 


Mainline 


Split Tree 


envco -Uoox 


CO -] foo.c 


CO ' 1 sp fit _ n ame foo.c 


envci foo.c 


ci too.c 


ci 'N split „ name foo.c 


envrcs-lfGox 


rcs-Itoox 


res -1 spl rt _ name too . c 



For the Split tree case, hy specifying a particular revision 
of a file when checking it out. we can randomly access any 
revision contained in the RCS file, not just the head. This 
is used in conjunction with the symbolic naming capability 
to check out the proper revision of a file for a given split. 

Changes made in the mainline never affect the split. For 
example, consider the situation in Fig, ti in which the file 
foocv has three revisions: 1.1» '^^2, and 1.3. Revision 1.3 is 
symbolically named mO. Checking a change to foo.c, v into 
the mainline will result in a new revision, 1.4. This new 
revision bet:onies the new^ head of foox,v. Since the symbolic 
name mO still paints to revision 1.3, the revision of foo.c,v 
used in the mO split is not affected. 

For the eheckin command in a split tree case, the symbolic 



File rod c.v Before 



File foox.v After 




Mainline - 



T 

▼ 



mO 



Fig, 6. An Bxampte showing how a change to the matnlme 
aoes not affect the split. 
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name is updated to refer to the newly checked-in revision. 
Furthermore, when a file is checked into a split, eui RCS 
branch may or may not be created. An RCS branch is created 
if the revision is not at the head of an existing branch [see 
Fig. 7). Otherwise, if the revision is at the head of an existing 
branch, including the trunk, then the new revision becomes 
the new head of that existing branch (see Fig 8). This func- 
tionality has some important ramilications. 

When checking a file into a split, in most cases it is 
desirable to propagate the changes through to the parent 
tree, which is usually the mainline. This is possible, indeed 
automatic, if the revision of the file for the split is the same 
as the revision for the parent. In this case, checking the 
file into the split aulomaticaliy checks the same revision 
into the parent. This functionality can be exploited in that 
many defect fixes can be made once in the split, then 
checked into both the split and the parent in one operation. 

In the case where the revision of the file for the split is 
not the same as the revision ofthe file for the parent, the 
changes cannot be propagated to the parent. In this case. 
a new branch is either created, or an existing hranch con- 
tinued. If the changes are to be propagated to the paient. 
then the file must be checked out, modified, and checked 
back into the parent environment. The RCS command 
rcsmerge is often used to merge in the changes semiauto- 
matically in this scenario. In practice, the automatic propa- 
gation case mentioned first occurs far more frequently than 
does the nonpropagation case* so there has not been much 
incentive to automate the case in which changes cannot 
be propagated io the parent. 

Although it is usually desirable to attempt to propagate 
defect fixes automatically from a split to its parent, in some 
cases this is not desired at all. In these cases, the user can 
force an RCS branch during check in. Again, in practice, 



this occurs very infrequently. 

Quality and Productivity Gains 

Many quality and productivity gains have resulted from 
the mechanism described in this article. First, development 
on new projects can continue independently in the main- 
line while a split is created for software slated for release 
(i.e., baseline software). Final functional test, which often 
takes four to six weeks, is done on the split, stablCf software. 
Changes to the stable software are limited to certain defect 
fixes and are extremely well -controlled. New development 
for future projects can take place simultaneously and inde- 
pendently in the mainline. In the past, new development 
(or at least file check-ins related to new development) had 
to cease during the several weeks of functional test, creating 
many bottlenecks, not to mention idle software engineers. 

Next, in the past, fi ies were simply copied from one place 
to another during the process of creating final [frozen] 
software. Once this was done, it was extremely difficult to 
propagate changes from one version of the software to the 
other reliably. This put an excessive burden on the software 
engineers charged with maintaining several completely 
separate versions of released software, and this generally 
manifested itself as a schedule slip during functional test as 
problems were uncovered. This problem has been reduced 
to manageable proportions by the parallel development 
mechanism described here. As discussed above, changes 
can in most cases be automatically propagated from a split 
[0 the mainline. Also, since all versions of the software are 
centralized in one set of RCS files, it is easy to track the 
status of ail software versions. Reports can be generated 
ftypically \na the riog and awk programs) to describe all the 
changes to a split since a certain date, time^ second, and 
so on. 
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Fig. 7. Creating an RCS branch when a revision /s not at the 
head of an existing branch. In this case foo,c.v has four revi- 
sions: l.t ^2, 7.3. and t4. Res/ision 13 is symbolicaliy 
named mo. Checking a change to foocv into the mo split 
forces the creation of the RCS branch 1.3.1.1. The symbodc 
nanne mo is updated to point to the new revision 1.3.1:1. 
Checking the change into the mO split does not result in its 
being checked into the mainline. 




Mainline 




Fig. 8, Making a change to a file when the revision is af the 
head of a branch- in this case too,c,v has three revisions: 7 J, 

1.2, and 1-3. Revision 1.3 is symboiically named with the 
spiit„name mO. Checking a change into foo.cv resufts in a new 
revision, 1 .4 The spilt _ name mO is updated to point to revision 
1.4. Since 1 4 is now the head of foo.c,v, this new revision is 
used by the mainline as well. 
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Thirds custom software loads in which several files [ei- 
ther experimental or from the mainliae) are added to a base- 
line of stable sofHvare (t^^ically a split), are much easier 
to generate with the mechanism described here. Because all 
versions of the software are kept in a single set of RCS files, 
it is easy to identify' and extract tiie proper revisions for 
the custom load. Furthermore, these customizations are 
ver\' well -coo trolled because they are built on a basehue 
of stable software. This is very important for ISY because 
field trials are often conducted to evaluate a single feature, 
with all other functionality' assumed to be unchanged from 
the given released software. In the past, generating custom 
software had the unpleasant side effect of iucorporatiag 
changes to files unrelated to the features under test. 

Final h% management is now able to assume that software 
splits are now not only possible, but reliable as well. This 
has allowed an additional degree of freedom in project 
planning which was not previously available. 



Ac kn o w iedg ments 

The author would like to acknowledge Dave Desormeaux 
[now at HP's Graphics Technology* Division in Fort Collins, 
Colorado) for his work in conceiving, designing, and imple- 
menting the original ISY Software De\'elopment Environ- 
ment over four years ago. Without his key contribution, 
building the parallel development extensions described 
here would have been immeasujably more difficult hi 
addition* the author would like to acknowledge Bill Harte 
of ISY for his many valuable design suggestions. Finally, 
the author would like to acknowledge the many ISY 
software engineers for their enhancement ideas. 



Conclusion 

The mechanism described here has been in use at ISY 
for approximately two years. During that time, the software 
environments for three major subsystems of the HP SONOS 
500/1000 ultrasound system have used the split mecha- 
nism a dozen times for both fomiaJ software releases and 
field trial software. These three subsystems are made up 
of approximately 1000. 500. and 300 source files. 

Although the use of RCS to implement parallel develop- 
ment capability has been highly successful within ISY, It 
is not perfect. First, there are some minor problems in the 
RCS toolset which require an awareness on some level, 
either by the software development environment adminis- 
trator, or by the software engineers themselves. As an exam* 
pie, the RCS tools do not allow concurrent access to an 
RCS file, so two users cannot check out different revisions 
of the same file at the same time. Another problem is that 
although the mechanism described in this article is ideally 
suited for splitting off software revisions which then 
become relatively stable (e,g., software release), it is not 
very well-suited for long-term parallel development in 
which multiple revision threads are all active and all 
equally important. This gels back to the ver>^ structure of 
an RCS file, which is a single, dominant trunk with an 
arbitrary but inferior branch structure. 

Overall however, the parallel development mechanism 
described here has been highly successful across multiple 
software development groups within ISY, It allows excel- 
lent control over stable software in conjunction with inde* 
pendent parallel development of new software. Best of all. 
the mechanism is simple and applicable to any software 
development environment In which RCS is used for revi- 
sion control. 
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Building and IVIanaging an Integrated 
Project Support Environment 

HP's Rosevitte Networks Division has developed an 
integrated, cost-effective computing environment tliat 
fosters cooperative computing and provides R&D engineers 
with easy access to the toots and methodologies for product 
development. 

by Ronald F. Richardson 



ONE OF THE WAYS to foster increased quality and 
productivity in an R&D environment is to provide 
consistently managed and maintained computing 
facilities that allow enoinoers to have easy access to the 
latest tools and metho do logics. In August 1988 the software 
quality and productivity team at HP's Roseville Networks 
Division (RND) was assigned the tasks of managing the 
overall R&D HP4JX computing faciMly and developing a 
foundation from which to build a highly integrated project 
support envirrinment. The primary goal of this effort was 
to provide a tool-supported softw^are engineering process 
huilt on sound engineering platforms to facilitate creating 
hetter products faster. Our challenge was establishing a 
computing strategy and direction for laboratory- wide coop- 
erative computing in an R&D organization that traditionally 
addressed their computing needs on a project-by-project 
basis. 

This paper discusses cost-effective HP-UX computing 
and ways of reducing the effort of maintaining and admin- 
istering this environment. The main areas discussed 
include financial aspects, cooperative computing, network 
Euchitecture, and a management model for system admin- 
istration, 

Financial Aspects 

The first hurdle we had to overcome was convincing 
senior management that workstations for software 
engineers made financial sense. The current environmenl 
was primarily based on central HP-UX timesharing sys- 
tems, Most of our software engineers had three to four 
terminals in their office to emulate a windowing environ- 
ment. This was required because in developing networking 
products many machines were used. Remote communica- 
tion from one machine to another via data switching was 
extremely time-consuming and multitasking was not easily 
achieved. Hardware engineers were just baginning to use 
w^orkstations within their areas* The financial situation 
required outfitting over 100 engineers wath workstations 
while keeping the cost per engineering seat close to the 
cost of multiple terminals or personal computers. 

Fortunately, at that time, HP's HP-UX development lab- 
oratory in Colorado had just finished developing the first 
version of HP-UX diskless workstations.^ Diskless systems 
have the advantages of a timeshared enviroiuiient while 



maintaining the performance of standalone workstations. 
In fact, depending on the configuration, performance 
exceeding that of a standalone system is possible. Advan- 
tages of diskless systems include: 

■ Centralized file system. The user sees a single file system 
from any w^orkstation, even though the file system may 
be loCfited far riwa}^ on a file server. 

■ Lower total system cost. Peripherals such as disks and 
tape drives are only needed for the file server. This sig- 
nificantly reduces the cost per user. 

■ Lower cost of ownership. With fewer mechanical parts 
[disks, tape drives, printers, etc.) maintenance costs are 
reduced over those of standalone systems. Additionally ► 
software support contract prices are also reduced. 

» Easier system administration. Administration focuses on 
the file server and the cluster disk, and support of the 
diskless nodes is no longer an issue. Contrast this with 
a standalone network in w^hich each machine is admin- 
istered individually. 

The financial model was not one of accounting genius 
but mainly common sense. R&D was evenly split between 
hardware and softw^are engineers. The hardware engineers 
were currently purchasing standalone workstations with 
four disks. Using diskless workstations and amortizing the 
cost of the server over eight nodes per cluster, a hardware 
engineer could be outfitted with an HP 9000 Series 36UC 
with 16M bytes of memory for 25% to 50% of the cost t i 
a standalone s^'Stem. As an additional checkpoint, our 
finance department used a standard accounting model to 
determine that a 7,2% productivity increase was required 
to achieve a 20% ROI (return on investment) on the work- 
stations over a five-year period. Subjective measures led 
us to believe that this productivity increase could be 
achieved. Given the savings associated with diskless work- 
stations, having an attainable productivity goal, and realiz- 
ing that softw^are engineers were undercapitalized relative 
to their hardw^are counterparts, funding was provided to 
p u rch a se 110 w o rkst atio ns . 

Architecture 

A successful diskless implementation is based on a well- 
designed and maintained netw^^ork. If a reliable netw^ork 
cannot be achieved, diskless is not the preferred distributed 
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Gomputing ertvironment. In this section we first look at the 
1(^1 cal model of our cooperative computing eDVtronment 
to obtain an overview of workstation and ser^-er organiza- 
tion, then review the physical model of the network topol- 
ogy including the lower layers {physical, link, and net- 
work), vi/hich provide the foundation of the network. 

Logical Model 

The essence of workstation organization ts a triad of s^^s- 
tems supporting a project team. The first system is the boot 
serv-er. This machine's primary functions are to provide 
HP-UX facihties to its configured diskless clients and swap- 
ping over the network. The second piece of the triad is the 
diskless clients. There is one of these diskless workstations 
in each engineer's office* The workstation is the engineer's 
user interface into the computing environment. Using X 
Windows, this is where most of the engineers perform their 
work ranging from schematic entry to C compdes. The final 
piece of the triad ts the project server. It acts as a file server 
and compute server for project -specific needs. Ail three of 
these components need to be highly integrated over a fast, 
reliable network. 

Physical Model 

A local area network must move packets of data from 
one host to another as quicidy, reliably, and efficiently as 
possible. The diskless configuration also requires the LAN 
to have minimal impact on the individual user (host). Not 
only should office connections to the network be unobtru- 
sivet but maintenance and reconfiguration should be virtu- 
ally unseen by the workstation user. If c:arefui choices are 
not made, there is the risk of maintenance problems later. 
Requirements. HP StarLAN 10* was chosen as the main 
transmission medinm connecting the triad of machines 
supporting (he project team. HP StarLAN 10 provides the 
same functionality as Ethernet, only over a 10-Mbyte/s 
twisted-pair cable with the added benefit that connections 
are like point-to-poinL Administration of the current R&D 

'Thcj HP StarLAJ^ produgta rnenttonad m Efirs paper h&ve tjeen updated and are ntfw edited 
Ihe EUi6rtw'i$l ^^ tsTjnily of net wort products. 



laboratory HP ThinL AN network, from a hardware perspec- 
tive, consisted of *install and forget until the network stops 
working/' This approach could not be taken with the new 
HP StarLAN 10 network because we would be servicing 
over too diskless workstations. Our problems included 
reconfLguiation, fault isolation, and traffic management. 

■ Reconfiguration. More hosts require continual expan- 
sion and reconfiguration of the network. These changes 
must have minimal effect on the current users. 

■ Fault isolation. Problems are inevitable— the more s^'^s- 
tems, the more faults. A failure, either hardware or 
software* should not affect the entire network, 

■ Traffic management. As the network grows, so does traf- 
fic. The abil ity to contain local traffic in one area becomes 
extremely imporfant with a diskless system. 

To address these issues we use HP StarLAN 10 hubs 
(multiport repeaters and wire centers) and bridges- 
Cabling Plan, The engineers' offices were wired with four- 
pair twisted-pair cable. This eight-wire cable is split into 
two four- wire portions: two pairs for phone and two pairs 
for HP StarLAN 10. We use HP StarL.AN 10 transceivers* 
to connect the workstations to the network. Unlike HP 
Thin LAN coaxial cable, which can be 185 meters in length 
and have 30 nodes attached to it, the HP StarLAN 10 cable 
has a 100-meter length re.striction and can only have one 
node attached much like a terminal point-to-point connec- 
tion. To bring together these multiple segments we use HP 
StarLAN 10 hubs to concentrate twelve segments at a single 
point. They are then interconnected via a standard HP 
ThinL^^N backbone segment (see Fig. 11. In addition to 
providing interconnect convenience ^ the HP StarLAN 10 
hubs provide electrical isolation of individual segments 
from the entire network. Should a cable become damaged, 
only the user on that segment is affected and troubleshoot- 
ing is much easier. 

Gateways. Like any repeater. HP StarLAN 10 hubs appear 
transparent to the interface on any host. Except for electri- 
cal problems on any given segment, repeaters do liltle to 
provide .segment isolation. To control and monitor network 

*HP SiarLAN IQ transceivers £yre at^o called msdia access unti5 [MAUsi' 
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traffic a device is needed that deals with levels of network- 
ing beyond the Ethernet level (i.e.. network layer of the 
Open Systems Inlerconnecl (OSI) Reference ModcJ). 

Since our network is exclusively internet protocol (IP) 
based, the obvious choice for such a device is an IP gateway 
or router. Part of the internet protocol is the concept of 
logical subnets. This concept and its ramifications are nut- 
side the scope of this paper, with one exception: logical 
subnets provide a method of breaking apart a network into 
a local setting or a wide area network Subnetting makes 
the division of local network traffic feasible. 

Broadcasts prove to be the most troublesome traffic prob- 
lem. Every interface that sees an address resolution pro- 
tocol or user datagram protocol broadcast interrupts its 
host processor even If the packet is not required by the 
host. As the network grows, more CPU time is spent servic- 
ing these broadcasts. The IP gateway provides a logical 
boundary and constrains subnet traffic, including broad- 
casts ^ to a particular LAN segment. 

We found that the organizational boundaries within our 
site suggest logical places for subnet partitions. Organiza- 
tional partitions distribute the administrative responsibili' 
ties of each subnet to the appropriate entity. The gateway 
indirectly provides a psychological division that enables 
each group or entity to control its own network (subnet), 
yet retain connectivity with the entire corporate networks 
To the user, a neighboring host appears the same as a host 
in a different subnet, no matter where the subnet may be 
physically located. 

Troubleshooting. Hardware problems are a constant source 
of worry for administrators of large networks. Certain tools 
are necessary to maintain and debug networks. When entire 
groups of hosts fail, the problem can usually be traced to 
a single segment failure, a hub failure, a bridge failure, or 
possibly a gateway failure. These types of problems are 
easy to find and correct. Since logical divisions are already 
in place, many of the more common problems are elimi- 
nated before a system administrator has to begin a binary 
host-to- host search for possible failures. The problems that 
cause the most difficulty are the host that occasionally 
transmits bad packets, or the segment that loses connectiv- 
ity to certain other hosts on the subnet because of 
irregularities in cabling. 

Conceptually we would like to know how well each host 
sees traffic (i.e. , what percentage of incoming packets are 
bad). We also want to know how other hosts on a subnet 
see packets from a specific host. As a first-order solution, 
the internet control-message protocol echo (pingj can be 
used to provide some information on the performance of 
a subnet. The usual test Is to send ping packets from one 
workstation to another and examine the error statistics on 
the returning packets, then proceed from machine to 
machine looking for a host or group of hosts with signifi- 
cantly more errors or a pattern of failed responses. A typical 
problem con Id be a host responding to only half the pings. 
This could indicate an electrical problem with the cable 
[e,g., the cable is too long). 

The method works most effectively when the problem 
is fairly solid. However, experience has shown us that more 
often than not, users perceive an intermittent performance 
loss on the network as a failure. A quick check reveals 



nothing wrong. Solving intermittent problems requires 
some long-term statistics gathering. For this we use a net- 
work protocol analyzer and HP BridgeMariager^ (personal- 
computer-based network management software for bridge 
interrogation). With a statistics application package it is 
possible to obtain detailed inforniation on any individual 
node as well as the network in general. Wc are able to 
gather such information as percent network use, error 
count, and collision count, in an understandable graphical 
format. Additionally, the protocol analyzer can provide 
these same statistics on any individual node or group of 
nodes. We have also used it effectively as a ping generator 
to check the performance of various hosts and gateways 
on the network. Given that the protocol analyzer is the 
most powerful device on the network in terms of frames 
per second* it can be dangerous and should only be used 
for stress testing during off-hours. 

If the protocol analyzer has one fault, it is that it cannot 
examine how a particular interface sees the netw^ork. Often, 
one node will see the network with many errors while its 
neighbor only a few feet away sees few errors. Typically 
these errors include bad frame checksums or misaligned 
frames. Usually* bad cable connectors, a defective trans- 
ceiver, or a bad tap are the causes of such problems. These 
types of errors may simply go undetected until a node with 
this problem attempts to connect to another node* where- 
upon the errors become so prevalent that reasonable data 
transfer is impossible. 

To detect these sorts of problems before the user notices, 
an administrator needs to see how each node on the net- 
work *'feels" about its interface. Since dragging the analyzer 
to each port on the net w^ould be impractical, we log in to 
each machine remotely to execute diagnostic tools such as 
landiag and ping. This allows us to interrogate each system's 
view of the network. 

Bringing It All Together 

Our data center physical environnient consists of a tradi- 
tional raised-floor management information systems (MIS) 
machine room. The diskless computing equipment shares 
this space with the HP 3000 machines that support the rest 
of the division. W^e have 10 boot servers that provide 100 
diskless clients with HP-UX facilities and swapping over 
the network. All boot servers have a standard configuration, 
allowing mutual backup in the event of a system failure. 
Each boot server is an HP 9000 Series 360C computer with 
BM bytes and a single HP 793 7H disk drive. All servers 
and their corresponding disks are rack -mounted in HP 
19514 A eight-pack cabinets. The console lines are run to 
multiplexer cards in another workstation in which each 
boot ser\'er has a dedicated console window. Ergonomics 
arc done quite nicely. 

In the mezzanine we have banks of HP StarLAN 10 hubs 
that support various areas of the office floor. Depending 
on project team location, their workstations will be con- 
nected to one or more of the hubs supporting that floor 
area. Each hub supports twelve ports and normally all 
members of a project teani share one hub* The project 
server, which is also in the office area, is connected to port 
two of a team's hub. The boot server for the project team, 
located in the data center, is connected to port one of their 
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hub. Tlie result is that all systems of the triad supporting 
the project team are physically on the same HP StarLAN 
10 hub. All network fiJe system (NFS) mounts and 
associated traffic are thus localized to one hub. In the event 
that the team generates too much network traffic, the hub 
is bridged from the HP ThiaLAN backbone as shown in 
Fig. 1. Because we are using twisted-pair cable and cross- 
connect blocks to make [he connections, patching between 
hubs, workstations, and servers is trivial (see Fig, 2), When 
engineers move, al! Jhey do is plug their workstations into 
the HP StarLAN 10 ports in their new offices. Their work- 
stations will automatically boot from the correct sen-^er. 
Once the entire project team is situated, the hoot sender is 
patched to the appropriate huh supporting their new- 
offices. 

Today our new HP StarLAN 10 network and the old HP 
ThinLAN network, which is used for the remaining stand- 
alone systems, share the same subnet in the gateway. The 
HP StarLAN 10 hubs provide the network with a method 
of expansion and fault isolation, within the user (office) 
environment and across the project team triad. Point-to- 
point functionality further increases fault isolation. The 
concept of subnets and the use of gateways add further flex- 
ibility to the network and their use will be expanded as 
traffic levels dictate. The twisted-pair cabling offered with 
HP StarLAN 10 makes reconfiguring the network to meet 
changing traffic patterns a trivial task. 

A Management Paradigm 
for System Administration 

Having effectively laid the computing foundation for 
future work toward building an integrated project support 
environment, the challenge of managing it arises. R&D com- 
puting facilities consist o'f many components, including 
the diskless environment just described. Wc wore faced 
with developing a support paradigm that would merge the 
best practices of other organizations managing computer 
facilities while retaining much of the "hands on, no con- 
trols" mentality traditional to an R&D envirooment. The 
three major computing environments within HP were 
evaluated and their merits weighed. 
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Computing Environments at Hewlett-Packard 

It is necessary to understand three computing environ- 
ments within HP to put the HP-UX support issue into per- 
spective. These computing envLronments are R&D, manu- 
facturing, and management information systems. Each 
environment is different in its focus» the metrics by which 
it is managed, and its hardware and software configura- 
tions. 

R&D Cotnptitittg. R&D compuling is often managed and 
administered from an R&D producti\it}^ department. This 
department lypically reports to the entity's R&D productiv- 
ity manager. The department staff are engiaeers and system 
administrators (or they may be system administrators who 
are engineers). This department manages all aspects of R&D 
compuling including installing applications, writing utili- 
ties, tuning performance, and designing and managing net- 
works- Most of the users of these services are engineers, 
although cross-functional applications bring in other users. 
Managing CAD systems, design information, and CASE 
tools seem to be the primary concerns in R&D computing. 

R&D computing is highly distributed and t\^icaily based 
on the HP-UX operating system running on HP 9000 sys- 
tems. The highest premium in this eniaronment is placed 
on productivity and ease of use of the various resources* 
Also, networking and connectivity are prime ser\aces to 
the R&D engineer. With the ever-shortening R&D cycles 
and increasing competition in HP's markets, any service 
allowing the R&D engineer to be more productive is highly 
valued. Security and control are acknowledged as impor- 
tant in this environment, hut the trend has clearly been to 
emphasize openness and not to sacrifice productivity for 
security and control. 

Information Systems Computing. Information systems 
computing is usually managed by an information systems 
department that reports to the entity or site information 
technology manager or entity controller. This department 
is responsible for all aspects of business computing and is 
accountable to entity management as well as HP corporate 
information systems- They may aiso be responsible for site 
communications and networks and the site data center. The 
department typically installs and supports all corporate- 
developed information systefos thai are ii.sed at the entity. 
A well-established internal audit process exists providing 
business control feedback on this group's performance. 

Intormatjon systems computing has traditionally been 
centralized {tevif machines, many terminals) atul primarily 
based on the MPE XL operating system and HP 3000 com- 
puters. The highest premium is placed on reliability, integ- 
rity* control, and .security. Secondary importance is placed 
on the effective use of resources and on ease of use. Of 
course, productivity is the driving motivation behind all 
information systems. However, the trend in information 
systems has clearly been to emphasize security and control, 
sometimes at the expense of individual user productivity. 
Manufacturing Computing. Manufacturing computing 
includes the elements found in R&D computing with two 
additional major areas of emphasis: process control and 
t;omputer integrated manufacturing (CIM). Manufacturing 
computing is usually managed from a combination of the 
following. 
■ Information systems departments [business systems) 
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■ R&D producli vity departments [engineering systems and 
R&D links) 

■ Manufacturing systems departments (business systems 
and CIM) 

■ Manufacturing engineering departments (engineering 
systems and CIM), 

The staff in these departments mcludes all types of infor- 
mation systems persomiel and engineers. 

The manufacturing computing environment encom- 
passes both the R&D and MIS environments. In manufactur- 
ing there exists a large mix of computers and operating 
systems including HP 3000, HP 9000, HP 1000, and HP 
Vectra computers running the tour major HP operating sys- 
tems [MPE XL. HP-UX, RTE, and MS-DOS*). There are 
also non-HP computer systems that control non-HP process 
equipment. The move toward GIM has placed great 
emphasis on heterogeneous computer architectures in 
manufacturing hecause of the large mix of available process 
control equipment. The issues of productivity- security, 
and control have about equal importance in manufacturing. 

Computing Support Model 

The goal of the computing support model is to achieve 
a balance between the high value placed on productivity 
and ease of use by R&D and the concerns about reliabiHtVT 
integrity, control, and security paramount to the MIS com- 
munity. To achieve this end. the model focuses not on the 
concerns stated above but on the data accessible and tasks 
performed on a given Ri^D HP-UX machine. From a security 
and control perspective, if a machine does not have data 
that could violate the rules of confidentially or harm the 
corporation by loss or disclosure, that machine does not 

MS-DOS is a Ll S rE^giaTered tradefr.arK ol Micro&ofi Corporation 



pose a security risk unless it can facilitate "hacking" a 
machine or network that contains sensitive data. From a 
productivity and ease-of-use perspective, based on the 
diskless environment using X Windows, any auditable 
service is instantly avaikbte by opening a window to the 
secure machine providing that service. By layering services 
across many machines, as opposed to the traditional model 
of all services being on all machines, tight controls can be 
instituted on tlie machines and services that require them 
and more openness can be maintained on machines that 
do not house those services. This paradigm shift was 
reviewed with the internal audit team in 1988 and was 
vdew^ed as a valid approach. 

Fig- 3 shows an overview of our computing support 
model. Colnr cndes are a^^signed to all the machines to 
indicate the level of service, the level of security and con- 
trol, and the predominant use of the machine. Red and 
yellow machines are used for product devf^lopment with 
the red machines designated for testing. The green 
machines have some development responsibility, but are 
primarily devoted to administrative and production - 
oriented engineering duties. 

Through the model we are successful at stratifying our 
computing services through color codes so that the appro- 
priate level of controh accountability, and access can be 
given to the right Individuals wnthout compromising the 
integritv of the overall computing cnvironmenh As an 
example, e-mail on HP-UX systems is viewed by the corpo- 
ration as an auditable ser\'^ice on a par with HP Desk on 
MPE XL. The model therefore considers this service green, 
Mail then must be managed on a secure green machine 
and mail messages are only allowed to flow between other 
green machines on the network. If an engineer is working 
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Rg. 4» Service modei matrices. Thme matrices define the 
services each organfzation is responsitfe for providing to the 
computing environment. 
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on a red machine, which is typical of the testing environ- 
ment, it is a minor inconvenience to open a window to a 
green machine offering mail. This approach ensures the 
integrity of mail confidRntiality and administration with a 
minimal productivity impact. 

Coliaboratfve Resources 

The st^rvifjK model matrices in Fig. 4 indiruite that we 
have five organizations supporting the R&D computing 
environment. Based on the color assigned to each machine, 
each organization supports different services and varying 
levels of service. For example* the technical computing 
f^nvironment service team, which is made up of two system 
administrators, is responsible for most sen ices on green 
systems (see the first matrix in Fig- 4), The tmsted user 
team [second matrix in Fig. 4) is made up of R&D engineers 
who have the responsibility of providing HP-UX system 
administration and most other activities on red machines. 
These two groups meet monthly to work collaboratively 
on solving laboratory- wide productivity issues related to 
the computing environment. The remaining three organiza- 
tions (information technologVr site telecnmmunications, 
and electronic maintenance) are used like subcontractors 
for providing basic services such as backups, cabling, and 
preventive maintenance. By placing our services on ma- 
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trices and overlaying them we can see any holes in cover- 
age. The support model lias helped us stratify our support 
services and understand their requirements such that the 
annual business audit is effectively addressed. By building 
collaborative support teams with strong management sup- 
port we are effectively bridging the gap between service 
pro\^ders and the end user. Because the trusted user team 
is effectively end users they help ensure that the customer's 
voice is incorporated into services provided. 

Conclusion 

Diskless systems have proven to be an outstanding first 
step toward implementing a cooperative computing envi- 
ronment. Each engineer has a CPU to perform general 
development tasks while the highly tuned project servers 
and hoot servers execute very specialized requests. In terms 
of hardware acquisition and maintenance costs, diskless 
computing is a very cost-effective alternative to standalone 
workstations. Diskless performance has met and Ln many 
cases exceeded our expectations. This must be qualified 
by indicating that the diskless clusters must be tuned to 
specific types of workloads. An optimum configuration for 
us has been eight to ten nodes per cluster. Past this point 
diskless performance begins to degrade over that of a stand- 
alone system. Using diskless clusters has provided monu- 
mental strides in HP-UX system administration. We suc- 
cessfully support over one hundred diskless workstations 
with just two systems administrators. The old support 
ratios were one systems administrator for every ten to fif- 
teen Stand-alone machines. Diskless computing has helped 
us achieve economies of scale in many areas. PIP StarLAN 
10 has also proven itself extremely wel I by providing point- 
to-point functionality. If a node is unplugged, it has no 
effect on the rest of the network. Compare this with an 
open occurring on a standard HP ThinLAN netw^ork. which 
can have adverse effects on all nodes. 

As well as it has worked for uSt the diskless workstation 
concept has been a problem in a few cases. For example^ 
hard w^ are engineers can generate some huge files and swap- 
ping over the network can cause performance problems. 
Because of this we use local swap disks for most of our 
hardware engineers. We use HP 7958 132-Mbyte disks. We 
had many of these left over from converting stand-alone 
systems to diskless clusters. Therefore, these disks had 



little financial impaci on the implementation. 

Managing NFS mounts so that the correct file systems 
are coming from tbe correct servers for each project team 
is not something to be taken lightly. We have been success- 
ful at managing this aspect but it takes a fair amount of 
work. It especially gets challenging when more than one 
project team shares a boot ser\^er. At least two project ser- 
vers are involved and they can occupy geographically dif- 
ferent areas in the office environment. This has an impact 
on which HP StarLAN 10 hub they are connected to and 
howr bridging is achieved. Again, we have been quite suc- 
cessful but we have room for improvement. 

We have successfully laid the computing foundation to 
build an integrated product support environment for our 
R&D Laboratory. We still lack a solid integration framework 
and the methods and tools to support all phases of the 
product life cycle. We have begun to experiment with a 
fourth component to onr cooperative computing platform, 
application servers. These machines house lab oratory- wide 
tools that cross proiect team boundaries. We have success- 
fully implemented two design capture system application 
servers for hardware design and an HP Teamwork applica- 
tion server for structured analysis and design for software 
engineers. We axe in the process of impiementing a labora- 
tory-wide Hl-LO"^ simulation application server and exper- 
imenting with SoftBench as our software engineering inte- 
gration framew^ork for CASE tools. 

The computing support model, truly collaborative sup- 
port teams, and strong management commitment have ena- 
bled us to achieve a score of eight on a scale of one to ten 
for our diskless environment according to those who man- 
age the environment and those that use it. 

Hf-LO Is a U.S. registered trademajlt of GenRad, inc. 
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